bug-binutils
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]