Re: linker section gc

[rth@cygnus.com (Richard Henderson)]

In article <19980701233246.A21545.cygnus.bfd@dot.cygnus.com>,
Richard Henderson <rth@cygnus.com> wrote:
>I don't actually remember when I started work on this feature,
>but it had to be October-ish.  At long last, I've committed
>the stuff to devo.

Ok, I now realize this has like zero context and probably makes
no sense to any one except those that have been looking over my
shoulder for the past who knows how long.

The basic idea is that we collect all of the object files as normal,
but as we are laying them out, we realize that some sections cannot 
be referenced, because there are no relocations to them.  This bit
is done by a simple mark and sweep.

The effect is enhanced by compiling the source with -ffunction-sections
and/or -fdata-sections, which will put each function or initialized
data item in its own section.  These are named .text.foo or .data.bar
to make it easy to write linker script patterns to merge them all back
together in the end.

The roots of the mark-and sweep are: the entry symbol, all symbols
marked with -u on the command line, all sections marked with KEEP
in the linker script, and the tables created by CONSTRUCTORS.

There is an additional feature that is of tremendous help to c++.
Ordinarily, the relocations used to implement virtual function
tables would inhibit a good bit of collection.  With some additional
information from the c++ front end we can determine which entries 
in the table are actually used, allowing us to smash to zero those
that aren't, allowing the methods that can never be called to be
collected.

Everything but the relatively small patches to gcc have been committed.



r~