This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Section garbage collection problem
- From: Denys Vlasenko <vda dot linux at googlemail dot com>
- To: Andi Kleen <andi at firstfloor dot org>
- Cc: binutils at sourceware dot org, "H.J. Lu" <hjl at lucon dot org>, Alan Modra <amodra at bigpond dot net dot au>
- Date: Wed, 19 Sep 2007 18:36:54 +0100
- Subject: Re: Section garbage collection problem
- References: <200709161942.25443.vda.linux@googlemail.com> <p73wsumvoxs.fsf@bingen.suse.de>
On Wednesday 19 September 2007 13:07, Andi Kleen wrote:
> Denys Vlasenko <vda.linux@googlemail.com> writes:
> >
> > Otherwise, ld will discard .smp_locks sections, because
> > there is no references to them from anywhere.
>
> Actually there should be a reference to it in the start/end labels
> which are referenced by the patching code.
>
> Unfortunately they are currently outside the section. All you need
> to do is to move them inside.
>
> e.g.
>
> __smp_locks = .;
> .smp_locks : AT(ADDR(.smp_locks) - LOAD_OFFSET) {
> *(.smp_locks)
> }
> __smp_locks_end = .;
>
>
> to (untested)
>
> .smp_locks : AT(ADDR(.smp_locks) - LOAD_OFFSET) {
> __smp_locks = .;
> *(.smp_locks)
> __smp_locks_end = .;
> }
I think GC is done by building a directed graph where
*input sections* are nodes and relocations are links.
Then, starting with section where executable entry points into,
and all KEEPed sections, ld traces which other input
sections are reachahble. Unreachable ones are thrown out.
The label __smp_locks in your example above is not
inside *input section*, it is added to *output section* -
after GC is done.
--
vda