binutils-2.17: --cref broken? Extra warnings and corrupted data

["Paul Nash" <nashpaulr at gmail dot com>]

Hello all,

I've done my best to narrow this down somewhat, but I'm not sure it's
good enough for Bugzilla yet.  I hope someone can help who knows more
about the internals of BFD and what's really supposed to be happening
here. It looks to me like memory is getting stepped on.

Note, this does not happen with various other versions of binutils
that I've tried, most certainly the binutils-2.17-pre CSL release.

I am seeing a situation where linking any binary with binutils-2.17 ld
using the --cref option causes lots of "symbol 'blah' missing from
main hash table" warnings.  The "blah" in these cases is complete
garbage.

I determined with gdb that at the time add_cref is called,
h->root.string is a valid string pointer.  What's causing the problem
is that later when the cref table is output, the underlying memory
behind that pointer has been corrupted. In one case I looked at, a
later bfd_zalloc call memset's all the memory around that string to 0.

It seems like a potentially simple fix would be to have add_cref copy
the string when inserting into its hash table. But I assume the reason
it does not do this is because the string is supposed to be valid and
unchanging in the presumed lifetime of the cref hash table, so why
waste the memory to copy.  So I'm reluctant to implement this hack
without understanding the cause.  But, knowing where this string is
really allocated and where it might be freed is beyond my bfd/ld
knowledge. :-(

Details
----------

I built binutils-2.17 from pur sources, configured like this:

   .././binutils-2.17/configure  --prefix=/usr/local/i686/4.1.1-1b
--enable-shared --with-lib-path=/usr/local/i686/4.1.1-1b/lib

A few small cross-arm patches are present, but I've got same results
without those.  It was built using gcc-4.1.1.

I can compile a very very simple test program, for example let's say
I main a file with:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[])
{
  printf("Hello cref!\n");
}

Now I compile this with: "gcc -c -o test.o test.c"

Now I link with: "ld --cref -o test -lc test.o"

And what will happen in my build is that a bunch of errors come out:

Cross Reference Table

Symbol                                            File
/tmp/ld-new: symbol `no symbol' missing from main hash table

/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2
/tmp/ld-new: symbol `no symbol' missing from main hash table

/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2
/tmp/ld-new: symbol `no symbol' missing from main hash table

/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2
/tmp/ld-new: symbol `no symbol' missing from main hash table

/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2
/tmp/ld-new: symbol `x\uffff8\uffff' missing from main hash table
x\uffff8\uffff
/usr/local/i686/4.1.1-1b/lib/ld-linux.so.2


-----> Here's what I found on one symbol I know has this problem in
my test exe:

Breakpoint 3, add_cref (name=0x81be448
"_dl_allocate_tls_init@GLIBC_PRIVATE", abfd=0x80e7818,
section=0xb7f03b80, value=0)
    at ldcref.c:159
159       if (h == NULL)
(gdb) enable 6 7 8
(gdb) c

------> So here we can see that name==0x81be448, and it's a valid
string. So I set a watchpoint for memory at that location to change
and, sure enough:

(gdb) watch *0x81be448
Hardware watchpoint 4: *136045640
(gdb) c
Continuing.
Hardware watchpoint 4: *136045640

Old value = 1600939103
New value = 0
0xb7dd3987 in memset () from /usr/local/i686/4.1.1-1b/lib/libc.so.6
(gdb) bt
#0  0xb7dd3987 in memset () from /usr/local/i686/4.1.1-1b/lib/libc.so.6
#1  0xb7ea3ac4 in bfd_zalloc (abfd=0x80efae0, size=748) at opncls.c:926
#2  0xb7eb8f2b in elf_i386_mkobject (abfd=0x80efae0) at elf32-i386.c:630
#3  0xb7ebc98c in bfd_elf32_object_p (abfd=0x80efae0) at elfcode.h:547
#4  0xb7ea1de3 in bfd_check_format_matches (abfd=0x80efae0,
format=bfd_object, matching=0xbfd23c6c) at format.c:169
#5  0x080555b4 in load_symbols (entry=0x80a20c0, place=0xbfd23cbc) at
ldlang.c:2323
#6  0x080562ad in open_input_bfds (s=0x80a20c0, force=0) at ldlang.c:2852
#7  0x0805a1de in lang_process () at ldlang.c:5476
#8  0x0805da28 in main (argc=6, argv=0xbfd23e54) at ldmain.c:459

Help?

-PN