This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: Link-Time Optimizations


On Fri, 11 Nov 2005 18:38:22 +0100, Javier Cabezas Rodríguez wrote:
> Thanks for the tip. But why can it interfere with libglade programs?

We've experimented with enabling garbage collection of symbols for apps by
default in the autopackage 1.2 development cycle (see
http://autopackage.org/). Obviously for our use case download size is
important, many end users are still on dial up especially in the
developing world.

Unfortunately it turns out that sometimes symbols are referenced by code
the garbage collector cannot see. One common case is where you have a
custom widget inside a glade file: the constructor will appear to be dead
code to the linker because the reference is stored in the .glade file
instead of in a .o file, so it will be eliminated causing widget
construction failure at runtime. This issue affects our very own GTK+
frontend!

The approach we're likely to take is to do two runs of the final link, one
with the garbage collector and one without (when constructing a package,
build time isn't really an issue). We can then show the developer:

a) How much space could be saved if the GC was enabled
b) A list of which symbols were eliminated
c) How to opt-in to get it

You can trivially work around the problem with something like:

   char volatile *tmp = &address_of_function;

which will stop ld optimizing the function out, but obviously it's up to
the developer to figure out which symbols need to stay and which really
are dead.

The space savings, especially when statically linking anything, can be
significant.

thanks -mike


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