[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/13811] New: --gc-sections --exclude-libs ALL leave undefined sym
From: |
chemobejk at gmail dot com |
Subject: |
[Bug ld/13811] New: --gc-sections --exclude-libs ALL leave undefined symbols referenced from garbage collected code |
Date: |
Mon, 05 Mar 2012 20:15:56 +0000 |
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: address@hidden
ReportedBy: address@hidden
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 ld/13811] New: --gc-sections --exclude-libs ALL leave undefined symbols referenced from garbage collected code,
chemobejk at gmail dot com <=