This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Listing and removing unused objects


In a message dated 1/25/2003 11:11:01 PM Eastern Standard Time, kazu@cs.umass.edu writes:
> Do you mean that the combination of -Wl,-gc-sections,-static and
> -ffunction-sections does not work for some reason?  On my system
> (RedHat 8.0 on AMD Athlon), the following works nicely.

There are three reasons GNU binutils ld --gc-sections won't work
for me:

1) It doesn't work at all on most non-linux-ELF targets.
Specifically, it doesn't work on cygwin and mingw, two targets I
care about in particular.

2) It doesn't work with dynamic linking.  See
http://sources.redhat.com/ml/binutils/2002-03/msg00351.html for an
explanation.  The general deal is that --gc-sections uses
relocation information to deduce unused sections, but there are
often implicit references to sections that may not be
trivially deduced when dynamically linking. (Occasionally it is
claimed that a symbol may be dynamically loaded at runtime, and
this is rare in typical programs, and -Bdynamic is not the default
anyway.)

IMO, having to compile with -static is often an unacceptable
constraint.  Part of the motivation for this feature is keeping
executable size down, but -static costs more than it is worth
in this case.  It is also often conceptually unfriendly
with what the program is trying to accomplish.

3) You need to use -ffunction-sections.  This makes object files
substancially larger.  On GCC 3.2.1 targetting i686-cygwin on
binutils 2.11.92, an object file with ten empty functions compiles
to 646 bytes normally, but 1406 bytes with -ffunction-sections.
Thats a 114% increase (1).  In addition, the GCC manual has this
to say:

"Only use these options when there are significant benefits from
doing so. When you specify these options, the assembler and
linker will create larger object and executable files and will
also be slower. You will not be able to use gprof on all systems
if you specify this option and you may have problems with
debugging if you specify both this option and -g."


Because of these things, --gc-sections is not an adequate solution
for me.

(1) While this is a degenerate case, it is very similar to
exactly the kind of real code I'd like to remove: my C++
code tends to have a lot of small, unused functions that
are only there to conform to an interface, and tend not to
be used in real code.  For example, of a typical container
class, most programs will probably use less than half
of its members. [Actually, in this case, containers are templated,
and unused members won't be emitted anyway.  It is
unfortunate GCC does not have a mechanism for doing this for all
functions.  It is my belief this is the way it "should be."]


Aaron W. LaFramboise


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]