headers
Martin Husemann | 1 Feb 2003 17:37
Picon

objdump -d dumps core

Just noticed that objdump -d tends to dump core on sparc64.

In a kernel compile dir:

# objdump -d tty_conf.o 

tty_conf.o:     file format elf64-sparc

Disassembly of section .text:

0000000000000000 <ttynullioctl>:
   0:   81 c3 e0 08     retl 
Segmentation fault(core dumped)

gdb says:

#0  0x40611198 in bcopy () from /usr/lib/libc.so.12
#1  0x4045594c in buffer_read_memory () from /usr/lib/libbfd.so.4
#2  0x40456848 in print_insn_sparc () from /usr/lib/libbfd.so.4
#3  0x10481c in dladdr ()
#4  0x105968 in dladdr ()
#5  0x106378 in dladdr ()
#6  0x1064bc in dladdr ()
#7  0x1065d0 in dladdr ()
#8  0x107b78 in main ()
#9  0x102784 in _init ()

Martin
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Husemann | 2 Feb 2003 02:17
Picon

Re: objdump -d dumps core

On Sat, Feb 01, 2003 at 05:37:40PM +0100, Martin Husemann wrote:

> Just noticed that objdump -d tends to dump core on sparc64.

I've fixed it. It happens when a branch instruction starts an object file:

tty_conf.o:     file format elf64-sparc

Disassembly of section .text:

0000000000000000 <ttynullioctl>:
   0:   81 c3 e0 08     retl 
   4:   90 10 3f fc     mov  -4, %o0

The code tried to look at the instruction before the retl (in this example)
and crashed.

Martin
Permalink | Reply | 0 comments |
headers
Christian Groessler | 3 Feb 2003 21:44
Picon
Favicon

cannot build cross toolchain under linux

Hi,

./build.sh -m i386 tools

fails in tools/texinfo:

.
.
.
cc  -O   -o ginfo  dir.o display.o dribble.o  echo-area.o filesys.o footnotes.o  gc.o indices.o info-utils.o 
info.o infodoc.o infomap.o  m-x.o man.o nodemenu.o nodes.o  search.o session.o signals.o  terminal.o
tilde.o variables.o  window.o doc.o key.o  ../lib/libtxi.a 
terminal.o(.text+0x40): In function `terminal_begin_using_terminal':
: undefined reference to `tputs'
terminal.o(.text+0x89): In function `terminal_begin_using_terminal':
: undefined reference to `tputs'
terminal.o(.text+0x101): In function `terminal_end_using_terminal':
: undefined reference to `tputs'
terminal.o(.text+0x14a): In function `terminal_end_using_terminal':
: undefined reference to `tputs'
terminal.o(.text+0x1e0): In function `terminal_goto_xy':
: undefined reference to `tgoto'
... many more references to tputs etc.

This is on a Debian/i386 box.

regards,
chris
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Bonnafous | 4 Feb 2003 08:59

build problem in src/libexec/ld.elf_so with MKPICINSTALL=no

hello,

I cross build NetBSD 1.6 (host i386, target sparc) with build.sh.
It works very well.

But when I use the MKPICINSTALL=no flag, nbmake stop in
src/libexec/ld.elf_so with this error :

---------
nbmake: don't know how to make /NetBSD/NetBSD-1.6-sparc/usr/lib/libc_pic.a. Stop
---------

I can find why... because in the ld.elf_so/Makefile there is special
stuff about libc_pic.a :

---------
DPADD+=	${CLIBOBJ}/libc_pic.a ${LIBC_PIC}

# One of these may not exist at link time, so avoid make errors.
${DPADD}:
	 <at> true
---------
at compile time, 
DPADD=/NetBSD/obj-sparc/lib/libc/libc_pic.a \
      /NetBSD/NetBSD-1.6-sparc/usr/lib/libc_pic.a

/NetBSD/obj-sparc is OBJDIR and /NetBSD/NetBSD-1.6-sparc is
DESTDIR. The first one exist and because of MKPICINSTALL=no the second
one doesn't exist.
(Continue reading)

Permalink | Reply | 0 comments |
headers
john heasley | 5 Feb 2003 03:00

cpp predefines

could someone tell me how names of platform specific cpp predefines are
chosen?

basically, going through some of the xfree source (from their cvs), they
have some source that reads:

#ifdef _LP64
# if defined(__sparcv9)
#  define       _MACH64_NAME            "sparcv9"

i understand that _LP64 comes from the sysv ABI (right?), but where did
__sparcv9 come from?  netbsd has __sparc_v9__.  i'm curious if i should
change the x source or ask toolchain-masters about adding __sparcv9.

guelah [27] gcc -dM -E - < /dev/null
#define __arch64__ 1 
#define __sparc64__ 1 
#define __NetBSD__ 1 
#define __SIZE_TYPE__ long unsigned int 
#define __GNUC_MINOR__ 95 
#define __PTRDIFF_TYPE__ long int 
#define __sparc_v9__ 1 
#define __GNUC__ 2 
#define __sparc__ 1 
#define __ELF__ 1 
#define _LP64 1 

thanks.
(Continue reading)

Permalink | Reply | 6 comments |
headers
matthew green | 5 Feb 2003 03:24
Picon
Favicon

re: cpp predefines


   could someone tell me how names of platform specific cpp predefines are
   chosen?

largely hysterical raisins.

   basically, going through some of the xfree source (from their cvs), they
   have some source that reads:

   #ifdef _LP64
   # if defined(__sparcv9)
   #  define       _MACH64_NAME            "sparcv9"

   i understand that _LP64 comes from the sysv ABI (right?), but where did
   __sparcv9 come from?  netbsd has __sparc_v9__.  i'm curious if i should
   change the x source or ask toolchain-masters about adding __sparcv9.

possibly we should add __sparcv9 -- it has always been defined in
solaris i think.  as is __sparc_v9__.  (there is also __sparc_v8__ 
for v8.)

   guelah [27] gcc -dM -E - < /dev/null
   #define __arch64__ 1 
   #define __sparc64__ 1 
   #define __NetBSD__ 1 
   #define __SIZE_TYPE__ long unsigned int 
   #define __GNUC_MINOR__ 95 
   #define __PTRDIFF_TYPE__ long int 
   #define __sparc_v9__ 1 
   #define __GNUC__ 2
(Continue reading)

Permalink | Reply | 5 comments |
headers
john heasley | 5 Feb 2003 09:08

Re: cpp predefines

Wed, Feb 05, 2003 at 01:24:20PM +1100, matthew green:
>    basically, going through some of the xfree source (from their cvs), they
>    have some source that reads:
>    
>    #ifdef _LP64
>    # if defined(__sparcv9)
>    #  define       _MACH64_NAME            "sparcv9"
>    
>    i understand that _LP64 comes from the sysv ABI (right?), but where did
>    __sparcv9 come from?  netbsd has __sparc_v9__.  i'm curious if i should
>    change the x source or ask toolchain-masters about adding __sparcv9.
> 
> possibly we should add __sparcv9 -- it has always been defined in
> solaris i think.  as is __sparc_v9__.  (there is also __sparc_v8__ 
> for v8.)

i dont have sunCC, but gcc from a solaris 9 box:

spruce [1] gcc -dM -E - < /dev/null
#define __HAVE_BUILTIN_SETJMP__ 1
#define __sparc 1
#define sun 1
#define __unix__ 1
#define unix 1
#define __SIZE_TYPE__ unsigned int
#define __GNUC_PATCHLEVEL__ 0
#define sparc 1
#define __unix 1
#define __PRAGMA_REDEFINE_EXTNAME 1
#define __USER_LABEL_PREFIX__
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Husemann | 5 Feb 2003 09:19
Picon

Re: cpp predefines

On Wed, Feb 05, 2003 at 08:08:06AM +0000, john heasley wrote:

> in this particular case, Xserver/XlcDL.c uses it to size an array and
> build a path.

Why not use the X specific defines here? SparcArchitecture and 
Sparc64Architecture IIRC.

(Not that I'm opposed to adding __sparc_v9)

Martin
Permalink | Reply | 1 comment |
headers
matthew green | 5 Feb 2003 16:53
Picon
Favicon

re: cpp predefines


   > __sparc64__ is the correct predefine to check for sparc64 in the
   > general case.

   i'd expect to see it on my solaris box.  what defines that as correct?

hmm.  use 'gcc -m64' to see what it does for 64 bit mode?
Permalink | Reply | 1 comment |
headers
john heasley | 5 Feb 2003 19:03

Re: cpp predefines

Thu, Feb 06, 2003 at 02:53:31AM +1100, matthew green:
>    
>    > __sparc64__ is the correct predefine to check for sparc64 in the
>    > general case.
>    
>    i'd expect to see it on my solaris box.  what defines that as correct?
> 
> 
> hmm.  use 'gcc -m64' to see what it does for 64 bit mode?

spruce [23] diff -u m32 m64
--- m32 Wed Feb  5 17:57:32 2003
+++ m64 Wed Feb  5 17:57:38 2003
 <at>  <at>  -3,7 +3,7  <at>  <at> 
 #define sun 1
 #define __unix__ 1
 #define unix 1
-#define __SIZE_TYPE__ unsigned int
+#define __SIZE_TYPE__ long unsigned int
 #define __GNUC_PATCHLEVEL__ 0
 #define sparc 1
 #define __unix 1
 <at>  <at>  -10,17 +10,18  <at>  <at> 
 #define __PRAGMA_REDEFINE_EXTNAME 1
 #define __USER_LABEL_PREFIX__ 
 #define __STDC_HOSTED__ 1
-#define __WCHAR_TYPE__ long int
-#define __WINT_TYPE__ long int
+#define __WCHAR_TYPE__ int
+#define __WINT_TYPE__ int
(Continue reading)

Permalink | Reply | 0 comments |

Gmane