This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Section garbage collection problem
- From: Michael Hennebry <hennebry at web dot cs dot ndsu dot NoDak dot edu>
- To: Denys Vlasenko <vda dot linux at googlemail dot com>
- Cc: Michael Hennebry <hennebry at web dot cs dot ndsu dot NoDak dot edu>, <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 16:03:15 -0500 (CDT)
- Subject: Re: Section garbage collection problem
On Wed, 19 Sep 2007, Denys Vlasenko wrote:
> On Sunday 16 September 2007 20:20, Michael Hennebry wrote:
> > Would a two-step link work?
> > The first step lets ld gc what it wants.
> > The second step links the output of the first with the
> > lock section and lives with the unresolved references.
>
> I don't understand you fully, sorry...
>
> NB: ld -r and --gc-sections don't mix. Thus first link
> in two-stage link should not use -r then.
That was my understanding.
> I am not sure how to use the result of
> "ld --gc-sections without -r" in the second stage.
ld --gc-sections -o middleman.elf most_input.o -lalllibs
As I understand the situation,
this would link but would not have the lock data.
ld -o final.elf --unresolved-symbols=report-all middleman.elf lock_data.o
This would link, but there would be unresolved
references from lock_data.o to gced sections.
If the references won't be used, they can be lived with.
If they can't be lived with,
perhaps the second stage output can be used either
to edit the source of lock_data.o or to add dummy
code that will resolve the references.
If two stages isn't enough, perhaps three is better.
--
Mike hennebry@web.cs.ndsu.NoDak.edu
"Horse guts never lie." -- Cherek Bear-Shoulders