Consider:
% head ref.s def.s
==> ref.s <==
.data
ptrsym:
.long badsym
.section .gnu.warning.badsym,"",@progbits
.string "badsym warning"
==> def.s <==
.comm badsym,4
% as --32 -o ref.o ref.s
% as --32 -o def.o def.s
% ar cqs def.a def.o
% ./ld/ld-new -m elf_i386 -o foo ref.o def.a
ref.o: In function `ptrsym':
(.data+0x0): warning: badsym warning
./ld/ld-new: warning: cannot find entry symbol _start; defaulting to
0000000008048054
ref.o: In function `ptrsym':
(.data+0x0): undefined reference to `badsym'
[Exit 1]
%
Tested on today's trunk ld. Gold does not have the same bug.
The trouble appears to arise in elf_link_add_archive_symbols, where the
presence of an entry for "badsym" because of the .gnu.warning.badsym
section interferes with the normal ("normal") arcane rules for whether or
not to pull in an archive member.
I initially thought the problem had to do with the especially arcane rules
for COMMON symbols in archives. But replacing def.s with:
.data
.globl badsym
badsym: .long 0
exhibits the same behavior.
This can only arise when a .gnu.warning.foo section is defined in a file
other than the one that defines foo. That is not how things are normally
done, but I don't think it's ever been said that you can't put a
.gnu.warning.foo section anywhere you like and expect it to take effect
whenever both that section is included anywhere in the link and there is
some reference to foo anywhere in the link.
This change fixes my test case (both the COMMON and plain-global variants).
But I know far too little about the nearby arcana to be sure it's a proper
fix or handles all related cases.
--- a/bfd/elflink.c
+++ b/bfd/elflink.c
@@ -5063,7 +5063,8 @@ elf_link_add_archive_symbols (bfd *abfd, struct
bfd_link_info *info)
if (! elf_link_is_defined_archive_symbol (abfd, symdef))
continue;
}
- else if (h->root.type != bfd_link_hash_undefined)
+ else if (h->root.type != bfd_link_hash_undefined &&
+ h->root.type != bfd_link_hash_warning)
{
if (h->root.type != bfd_link_hash_undefweak)
defined[i] = TRUE;
Thanks,
Roland
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
