http://sourceware.org/bugzilla/show_bug.cgi?id=13811
Bug #: 13811 Summary: --gc-sections --exclude-libs ALL leave undefined symbols referenced from garbage collected code Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sourceware.org ReportedBy: chemob...@gmail.com Classification: Unclassified Created attachment 6261 --> http://sourceware.org/bugzilla/attachment.cgi?id=6261 tar file with the example files for the reproducer I first encountered this problem with older ARM toolchains, but with my test case (see attachement) I have been able to reproduce it also with the x86 toolchain on Fedora 16. So I think this is a general problem in ld. $ ld --version GNU ld version 2.21.53.0.1-6.fc16 20110716 ld --gc-sections --exclude-libs ALL leaves undefined symbols in shared libraries that are only referenced from garbage collected code. In the example: - all code is compiled with GCC's -ffunction-sections -fdata-sections to optimize it for ld's --gc-sections - libshared.c/libshared_funcA() references libstatic_funcA() - libstatic.c contains functions libstatic_funcA() and libstatic_funcB() - libstatic.c/libstatic_funcB() references libhidden_funcA() - libstatic.c ends up in libstatic.a - libshared.so is linked from libshared.o and libstatic.a using --gc-sections --exclude-libs ALL The linker drops the code for libstatic_funcB() during GC, but the resulting shared library has an undefined symbol libhidden_funcA(). I.e. the library references something which isn't used anywhere in the code. This makes the shared library unusable, because you can't load it or link against it, unless of course libhidden_funcA() is coming from somewhere else. Running the example: $ make cc -fpic -ffunction-sections -fdata-sections -c -o test.o test.c cc -fpic -ffunction-sections -fdata-sections -c -o libshared.o libshared.c cc -fpic -ffunction-sections -fdata-sections -c -o libstatic.o libstatic.c ar rcs libstatic.a libstatic.o ld -shared -Bsymbolic -nostdlib \ --gc-sections --exclude-libs ALL \ --no-undefined \ -o libshared.so -Map libshared.map \ libshared.o libstatic.a cc -o test.exe test.o -L. -lshared ./libshared.so: undefined reference to `libhidden_funcA' collect2: ld returned 1 exit status make: *** [test.exe] Error 1 $ readelf --wide -s libshared.so | fgrep -e libstatic -e libhidden 2: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND libhidden_funcA 10: 0000000000000000 0 FILE LOCAL DEFAULT ABS libstatic.c 11: 000000000000023c 6 FUNC LOCAL DEFAULT 4 libstatic_funcA 14: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND libhidden_funcA $ cat libshared.map Archive member included because of file (symbol) libstatic.a(libstatic.o) libshared.o (libstatic_funcA) Discarded input sections ... .text.libstatic_funcB 0x0000000000000000 0xb libstatic.a(libstatic.o) ... $ fgrep libstatic_funcB libshared.map .text.libstatic_funcB $ objdump -d libshared.so libshared.so: file format elf64-x86-64 Disassembly of section .text: 0000000000000231 <libshared_funcA>: 231: 55 push %rbp 232: 48 89 e5 mov %rsp,%rbp 235: e8 02 00 00 00 callq 23c <libstatic_funcA> 23a: 5d pop %rbp 23b: c3 retq 000000000000023c <libstatic_funcA>: 23c: 55 push %rbp 23d: 48 89 e5 mov %rsp,%rbp 240: 5d pop %rbp 241: c3 retq So why does libhidden_funcA() end up in the symbol table? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils