Home Original page

[PATCH] Implement a command line switch to prevent section GC from removing exported symbols

fincs fincs fincs.alt1@gmail.com
Wed Dec 14 00:18:00 GMT 2016 
Recently, I have had the issue where I wanted to create an ELF
executable with exported symbols
(that is, their visibility is explicitly set to 'default' whereas the
other symbols are 'hidden').
It looks like LD can detect this situation when building ELF shared
objects and correctly behave.
However in the case of normal executables, LD will discard unused
sections anyway. This is probably
due to the fact that most applications and static libraries are
compiled without -fvisibility=hidden.

This problem can arise in certain cases when the main application
wants to export symbols for
use by shared libraries (plugins), while at the same time dead code
elimination and ELF dynamic
section size reduction optimizations are applied. It can also happen
during the development of
hobbyist operating systems that make use of custom executable formats
that are converted from ELFs.
Some people in the past have apparently encountered this problem too:

http://osdir.com/ml/gcc.g++.general/2006-04/msg00025.html
https://lists.freedesktop.org/archives/systemd-devel/2014-November/025626.html

Current workarounds involve having to manually assemble a list of
symbols to preserve and passing it
to the linker's command line, or alternatively linking in an
additional dummy object that references
every single symbol to be kept. An example of this workaround being
used can be found in the following discussion:

http://osdir.com/ml/gcc.g++.general/2006-04/msg00036.html

This seems like an inelegant and unmaintainable solution so I propose
adding a command line switch to LD that
enables the behaviour that already exists in shared object linking for
any kind of ELF executable. Please see
attached patch implementing my proposal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc-keep-exported.patch
Type: application/octet-stream
Size: 3009 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20161214/07ab6740/attachment.obj>
More information about the Binutils mailing list