This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
- To: Linus Torvalds <torvalds at transmeta dot com>
- Subject: Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Fri, 12 Feb 1999 20:19:31 -0700
- cc: Mike Stump <mrs at wrs dot com>, zack at rabi dot columbia dot edu, egcs at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <Pine.LNX.3.95.990212190247.31280Q-100000@penguin.transmeta.com>yo
u write:
> On Fri, 12 Feb 1999, Mike Stump wrote:
> >
> > You like the bleeding edge... Use -ffunction-sections, and
> > -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
> > sure, no problem.
>
> Hey, does that actually work reliably?
The -ffunction-sections code has been around for a while and as far as I
know works reliably on targets which use ELF or SOM object formats.
Other object formats may or may not support -ffunction-sections either due
to object format limitations or gcc implementation details on those targets.
-ffunction-sections was originally designed to allow for the linker to
reorder functions to improve icache & tlb behavior. It turns out the same
technology (putting each function into its own section) greatly simplifies
the garbage collection of unused functions. The docs are probably in need of
updating since they're probably somewhat biased towards the original use
of -ffunction-sections.
The linker support for garbage collection is newer and I don't have a lot
of experience with it. I would tend to believe that the basic garbage
collection ought to work pretty well since it's just mark, sweep & discard.
Stuff like garbage collecting entries in C++ virtual tables is more on the
bleeding edge and requires more cooperation between the compiler, assembler
and linker.
jeff