This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Get rid of some ugly code
- To: binutils at sourceware dot cygnus dot com
- Subject: Re: Get rid of some ugly code
- From: Alan Modra <amodra at bigpond dot net dot au>
- Date: Sun, 24 Jun 2001 00:35:01 +0930
- References: <20010623203547.M4573@bubble.local>
On Sat, Jun 23, 2001 at 08:35:47PM +0930, Alan Modra wrote:
> * elf32-i386.c (elf_i386_relocate_section): Replace ugly
> complicated tests for unresolvable relocs with a simple direct
> scheme using "unresolved_reloc" var.
I may have committed this a little too quickly as I'm getting
"eval.os(.stab+0x1388): unresolvable relocation against symbol
`__strtol_internal@@GLIBC_2.0"
when building dlfcn/libdl.so in current glibc sources. Also, the
R_386_GOT32 test for unresolved relocs was a little too lax.
This puts us back to where we were before.
bfd/ChangeLog
* elf32-i386.c (elf_i386_relocate_section <R_386_GOT32>): Tighten
unresolved_reloc test to exclude cases where we use "relocation"
before setting it to point into the .got. Reinstate fudge for
unresolved relocs in debugging sections.
I'm not really happy about the kludge though. See the FIXME below.
As far as I can make out from ChangeLogs, Ian made a change to emit
relocs in debugging sections on 1996-12-05, which was negated by
Ulrich Drepper on 1998-12-01. A pity public binutils CVS doesn't go
back that far so I could see exactly what the patches do. Grumble.
Anyway, that must have caused a problem, which Richard Henderson had
a go at fixing on 1998-12-10, further refined by H.J. Lu on 2000-04-20.
So, can anyone say why shared libs should lose all their .stab (and
other debug section) relocs?
--
Alan Modra
Index: bfd/elf32-i386.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-i386.c,v
retrieving revision 1.31
diff -u -p -r1.31 elf32-i386.c
--- elf32-i386.c 2001/06/23 11:01:44 1.31
+++ elf32-i386.c 2001/06/23 14:07:49
@@ -1586,6 +1586,8 @@ elf_i386_relocate_section (output_bfd, i
h->got.offset |= 1;
}
}
+ else
+ unresolved_reloc = false;
}
else
{
@@ -1632,7 +1634,6 @@ elf_i386_relocate_section (output_bfd, i
abort ();
relocation = htab->sgot->output_offset + off;
- unresolved_reloc = false;
break;
case R_386_GOTOFF:
@@ -1810,7 +1811,15 @@ elf_i386_relocate_section (output_bfd, i
break;
}
- if (unresolved_reloc)
+ /* FIXME: Why do we allow debugging sections to escape this error?
+ More importantly, why do we not emit dynamic relocs for
+ R_386_32 above in debugging sections (which are ! SEC_ALLOC)?
+ If we had emitted the dynamic reloc, we could remove the
+ fudge here. */
+ if (unresolved_reloc
+ && !(info->shared
+ && (input_section->flags & SEC_DEBUGGING) != 0
+ && (h->elf_link_hash_flags & ELF_LINK_HASH_DEF_DYNAMIC) != 0))
(*_bfd_error_handler)
(_("%s(%s+0x%lx): unresolvable relocation against symbol `%s'"),
bfd_get_filename (input_bfd),