ld i386 differences 2.10.2 / 2.12
Alan Modra
amodra@bigpond.net.au
Tue Mar 26 21:45:00 GMT 2002
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);
More information about the Binutils
mailing list