Re: Problem with linker with binutils-040414

["H. J. Lu" <hjl at lucon dot org>]

On Wed, Apr 14, 2004 at 12:43:36PM -0400, Daniel Kulp wrote:
> 
> 
> I'm having a problem using the "ld" built with the 040414 version of 
> binutils on Linux/x86.  For my large C++ application which consists of 
> several large shared libraries, it builds and links the first several 
> libs just fine.  However, at one point (same point every time), it core 
> dumps.  All I see 
> is:
> collect2: ld terminated with signal 11 [Segmentation fault]
> 
> I was using a version ld that I build several weeks ago from the cvs 
> source (don't know the exact date), and that works fine.   

# ./ld -V

will tell you the date.

> 
> I built a debug version of ld and loaded the resulting core into gdb and 
> the backtrace is:
> 
> #0  0x08066e14 in bfd_archive_filename (abfd=0x0) at bfd.c:515
> 515       if (abfd->my_archive)
> (gdb) backtrace
> #0  0x08066e14 in bfd_archive_filename (abfd=0x0) at bfd.c:515
> #1  0x0809124d in elf_link_add_object_symbols (abfd=0x829f4a8, 
> info=0x810c660)
>     at elflink.c:3641

It looks like old_bfd is NULL, which isn't supposed to happen. Can
you find out why old_bfd is NULL at elflink.c:3641? We need a testcase.
You can print out what `h' points to at elflink.c:3641 and find out
where the symbol is defined and referenced. You should be able to
construct a very small testcase from there.

> #2  0x080927fb in bfd_elf_link_add_symbols (abfd=0x829f4a8, 
> info=0x810c660)
>     at elflink.c:4380
> #3  0x08051f0d in load_symbols (entry=0x81154cc, place=0xbfffb4e8) at 
> ldlang.c:1475
> #4  0x0805281c in open_input_bfds (s=0x81154cc, force=1) at ldlang.c:1888
> #5  0x08052788 in open_input_bfds (s=0x81154bc, force=0) at ldlang.c:1860
> #6  0x08055ca2 in lang_process () at ldlang.c:4172
> #7  0x0805940e in main (argc=60, argv=0xbfffb644) at ldmain.c:466
> 
> I have confirmed that on line 3637 of elflink.c, old_bfd is null and thus 
> the call to bfd_archive_filename cores.    If I have that method return 0 
> if abfd is null, it no longer core dumps.   Instead, I get warnings:
> /usr/bin/ld: Warning: size of symbol `getpwuid_r@GLIBC_2.0' changed from 
> 385 in (null) to 392 in /lib/libc.so.6
> /usr/bin/ld: Warning: size of symbol `getrlimit@GLIBC_2.0' changed from 59 
> in (null) to 58 in /lib/libc.so.6
> /usr/bin/ld: Warning: size of symbol `realpath@GLIBC_2.0' changed from 54 
> in (null) to 64 in /lib/libc.so.6
> 
> 
> Let me know if more information is needed.   I cannot send the libraries 
> and stuff that are involved.  I may be able to send the core file.    I'd 
> like to make sure this is fixed before 2.15 officially goes out the door 
> as I like the speed improvements.  However,  a core dump is definitely 
> not a good thing.
> 
> Thanks!


H.J.