Re: ld i386 differences 2.10.2 / 2.12

[Alan Modra <amodra at bigpond dot net dot au>]

On Tue, Mar 26, 2002 at 02:52:54PM -0800, David O'Brien wrote:
> 
> The bug appears to be triggered when compiling a dynamic binary (does not
> happen when 'cc -static' is used) using GCC 2.95.4 in code that uses this
> macro:
> 
>     #define	__warn_references(sym,msg)	\
>         __asm__(".section .gnu.warning." #sym);	\
>         __asm__(".asciz \"" msg "\"");	\
>         __asm__(".previous")
> 
> If I use bfd/elf32-i386.c rev 1.51 rather than 1.52 (reset of files -D
> '9/29/2001 06:22:00 UTC') I do not get the segfault.

This one was a little tricky.  See the comment in the patch.

	* elf32-i386.c (allocate_dynrelocs): Follow warning symbol link.

In fact, I'm going to think about this for a while before applying,
because I think we may have a bug in elf_adjust_dynamic_symbol too.
That may be a better place to correct the problem.

(gdb) p *h
$3 = {root = {root = {next = 0x0, string = 0x8133bc0 "mktemp", 
      hash = 100717032}, type = bfd_link_hash_warning, next = 0x0, u = {
      undef = {abfd = 0x8162728}, def = {value = 135669544, section = 0x0}, 
      i = {link = 0x8162728, warning = 0x0}, c = {size = 135669544, 
        p = 0x0}}}, indx = -1, dynindx = -1, dynstr_index = 0, 
  elf_hash_value = 0, weakdef = 0x0, linker_section_pointer = 0x0, verinfo = {
    verdef = 0x0, vertree = 0x0}, vtable_entries_size = 0, 
  vtable_entries_used = 0x0, vtable_parent = 0x0, got = {refcount = 0, 
    offset = 0}, plt = {refcount = 0, offset = 0}, size = 0, type = 0 '\0', 
  other = 0 '\0', elf_link_hash_flags = 273}

h->elf_link_hash_flags == (ELF_LINK_NON_ELF
			   | ELF_LINK_HASH_REF_REGULAR_NONWEAK
			   | ELF_LINK_HASH_REF_REGULAR)

(gdb) p *((struct elf_link_hash_entry *) h->root.u.i.link)
$4 = {root = {root = {next = 0x0, string = 0x8133bc0 "mktemp", 
      hash = 100717032}, type = bfd_link_hash_defined, next = 0x8162728, u = {
      undef = {abfd = 0xa0}, def = {value = 160, section = 0x813b384}, i = {
        link = 0xa0, warning = 0x813b384 "\213;\023\bf"}, c = {size = 160, 
        p = 0x813b384}}}, indx = -1, dynindx = 15, dynstr_index = 16, 
  elf_hash_value = 0, weakdef = 0x0, linker_section_pointer = 0x0, verinfo = {
    verdef = 0x0, vertree = 0x0}, vtable_entries_size = 0, 
  vtable_entries_used = 0x0, vtable_parent = 0x0, got = {refcount = 0, 
    offset = 0}, plt = {refcount = 0, offset = 0}, size = 19, type = 2 '\002', 
  other = 0 '\0', elf_link_hash_flags = 6}

here, elf_link_hash_flags == (ELF_LINK_HASH_REF_DYNAMIC
			      | ELF_LINK_HASH_DEF_REGULAR)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Index: bfd/elf32-i386.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-i386.c,v
retrieving revision 1.65
diff -u -p -r1.65 elf32-i386.c
--- elf32-i386.c	2002/02/19 12:40:23	1.65
+++ elf32-i386.c	2002/03/27 05:32:01
@@ -1251,9 +1250,14 @@ allocate_dynrelocs (h, inf)
   struct elf_i386_link_hash_entry *eh;
   struct elf_i386_dyn_relocs *p;
 
-  if (h->root.type == bfd_link_hash_indirect
-      || h->root.type == bfd_link_hash_warning)
+  if (h->root.type == bfd_link_hash_indirect)
     return true;
+
+  if (h->root.type == bfd_link_hash_warning)
+    /* When warning symbols are created, they **replace** the "real"
+       entry in the hash table, thus we never get to see the real
+       symbol in a hash traversal.  So look at it now.  */
+    h = (struct elf_link_hash_entry *) h->root.u.i.link;
 
   info = (struct bfd_link_info *) inf;
   htab = elf_i386_hash_table (info);