This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

bus errors on ld (was Re: as,nm,ar segfaulting while building libgcc)


On Fri, Oct 13, 2000 at 11:00:13AM +1100, Alan Modra wrote:
> On Thu, 12 Oct 2000, Phil Edwards wrote:
> 
> > I'm using current CVS binutils+gcc in a unified tree.  (Yah, Mr. Bleeding
> > Edge am I...)  Doing a build of gcc on sparc-sun-solaris2.8 causes a number
> > of coredumps, all from the freshly-built binutils, all SEGVs:
> 
> Sounds very likely a gcc bug, but you may have hit a brand-new binutils

Those errors seem to have been bugs in gcc.  /Today's/ CVS builds without
any of those tools coring.

Now we're seeing a lot of bus errors from the linker.  In the testsuite
for libstdc++-v3 (which is where all this comes from), these errors build up:

    collect2: ld terminated with signal 10 [Bus Error]
    /usr/lib/libc.a(iconv.o): In function `iconv_open_private':
    iconv.o(.text+0xcollect2: ld terminated with signal 10 [Bus Error]
    /usr/lib/libc.a(iconv.o): In function `iconv_open_private':
    iconv.o(.text+0xcollect2: ld terminated with signal 10 [Bus Error]
    /usr/lib/libc.a(iconv.o): In function `iconv_open_private':
    iconv.o(.text+0xcollect2: ld terminated with signal 10 [Bus Error]
    /usr/lib/libc.a(iconv.o): In function `iconv_open_private':

which is seriously weird.

Anyhow, here's a look at one of the ld cores:

maple 1% gdb --quiet --nw            
(gdb) file /usr/local/SW/GCC/2.97-20001016-v3/bin/ld 
Reading symbols from /usr/local/SW/GCC/2.97-20001016-v3/bin/ld...done.
(gdb) core ./core.ld.24721
Core was generated by `/usr/local/SW/GCC/2.97-20001016-v3/lib/gcc-lib/sparc-sun-solaris2.8/2.97/../../'.
Program terminated with signal 10, Bus Error.
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1
#0  0x22904 in vfinfo (fp=0xba118, fmt=0x8b6d2 ")", arg=0xffbee75c)
    at ../../unified/ld/ldmisc.c:137
137                     bfd_vma value = va_arg (arg, bfd_vma);
(gdb) info stack
#0  0x22904 in vfinfo (fp=0xba118, fmt=0x8b6d2 ")", arg=0xffbee75c)
    at ../../unified/ld/ldmisc.c:137
#1  0x2335c in lfinfo (file=0xba118, fmt=0x8b6c8 "%s(%s+0x%v)")
    at ../../unified/ld/ldmisc.c:522
#2  0x22ff4 in vfinfo (fp=0xba118, 
    fmt=0x8ad02 ": undefined reference to `%T'\n", arg=0xffbee928)
    at ../../unified/ld/ldmisc.c:361
#3  0x232a8 in einfo (fmt=0x8ad00 "%C: undefined reference to `%T'\n")
    at ../../unified/ld/ldmisc.c:455
#4  0x1fb2c in undefined_symbol (info=0xba43c, name=0x70bbb8 "_dlopen", 
    abfd=0x66eaa0, section=0x70b170, address=488, fatal=true)
    at ../../unified/ld/ldmain.c:1216
#5  0x3838c in elf32_sparc_relocate_section (output_bfd=0xc3350, info=0xba908, 
    input_bfd=0x66eaa0, input_section=0x70b170, contents=0x897028 "\003", 
    relocs=0x70bf70, local_syms=0xa4b358, local_sections=0x889190)
    at ../../unified/bfd/elf32-sparc.c:1248
#6  0x43ab8 in elf_link_input_bfd (finfo=0xffbeeb88, input_bfd=0x66eaa0)
    at ../../unified/bfd/elflink.h:5704
#7  0x41c10 in bfd_elf32_bfd_final_link (abfd=0xc3350, info=0xba908)
    at ../../unified/bfd/elflink.h:4573
#8  0x207f4 in ldwrite () at ../../unified/ld/ldwrite.c:536
#9  0x1e428 in main (argc=29, argv=0xffbeed24) at ../../unified/ld/ldmain.c:372
(gdb) 


Does this help?

Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]