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: 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


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