Related articles |
---|
Removing unused sections from dynamically linked executables with UNIX awlaframboise@aol.com (2003-01-12) |
From: | awlaframboise@aol.com (AWLaFramboise) |
Newsgroups: | comp.compilers |
Date: | 12 Jan 2003 17:58:26 -0500 |
Organization: | AOL http://www.aol.com |
Keywords: | linker, optimize, question, comment |
Posted-Date: | 12 Jan 2003 17:58:26 EST |
Hi,
I am looking for a way to remove unused sections from
dynamically-linked executables.
Platforms which are of particular interest to me are i386-linux-elf
and i386-win32-pe, but information with regards to other platforms is
interesting as well. I am mostly concerned with GNU binutils and GCC.
In my particular instance, I am working with C++ code. It is common
in my code for many functions to be defined, for purposes of
fullfilling interface requirements, that are never used. (Example: I
may write a container class that defines many methods for insertion,
deletion, etc, but the client code only uses a small subset of these.)
Ordinarily, with GNU development tools, these functions are retained
in the final executable, even though nothing actually uses them. It
has occured to me that it is very possible there may be, in some
particular executable, more unused functions than functions actually
being used!
Currently, I have found two ways to accomplish this, neither of which
are acceptable:
1) Put each function in a separate translation unit before
compilation. This is unacceptable because it is overly intrusive into
design, and will obfuscate and inhibit good style in my project.
(Example: It would be silly, in my opinion, to have a container class
with 30 accessors be spread over 30 files. It would also have severe
performance penalties at compiletime when having to recompile
depended-on headers 29 times more than necessary.)
2) When compile translation units, put each 'object' (function,
variable, whatever) into a separate section (in GCC,
-ffunction-sections, -fdata-sections), then link statically and
collect unused sections (--gc-sections). This is unacceptable
because, in most cases, I do not actually want to link statically, and
the penalties of code duplication from static linking would outweigh
any benefit I get from removing unused objects.
I must admit it is not clear to me why the restriction is placed that
--gc-sections may only be used when statically linking. I understand
that if -export-dynamic is specified, code at runtime may attempt to
resolve previously unused symbols, so --gc-sections may cause a
problem here. But what about when this option is not specified, in
the usual case, when there is no possible runtime dependency (as far
as I know) upon unused symbols? Why may we not garbage collect
sections that could not possibly (as far as I can tell) ever be used?
Honestly, in searching for an answer to this question, I was quite
suprised that there was very little interest in doing this kind of an
optimization, or that noone seems to have a problem with substancial
unused code being in an executable. Yet, as someone who often finds
himself limited in storage and bandwidth resources, I greatly value
storage efficiency..
I would appreciate any help with regards to this issue. Any pointers,
code, suggestions, comments, referals, references to other sources,
whatever, would be greatly appreciated.
Thanks,
Aaron W. LaFramboise
awlaframboise@aol.com
[The AIX XCOFF linker collects unused routines. I don't know of any
other Unix linkers that do. I imagine that the reason that
--gc-sections doesn't collect in dynamically linked programs is that a
module loaded using dlopen() might call back to an otherwise unused
routine. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.