[Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions

[xinliangli at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19446

--- Comment #9 from David Li <xinliangli at gmail dot com> ---
(In reply to Nick Clifton from comment #8)
> Hi David,
> 
>   Right - I think that I have got a handle on what it going on here.
> 
>   So what happens is this - g0 is a data symbol.  In your case it is a
> common symbol, but it could equally be an ordinary data symbol too.  Either
> way it is present in unref2.o.
> 
>   When the linker is invoked it sees that g0 is only ever referenced from
> UNREF an unallocated, unloaded section.  So it has two choices.  It can
> either a) decide that since UNREF will never be loaded that there is no need
> to allocate space for g0 in the runtime image or b) decide that g0 is
> referenced by something it must have space allocated to it and so it is put
> into the .bss section.  The LD linker makes choice a), GOLD makes choice b).
> 
>   The results of garbage collection are then affected by this choice.  With
> LD, since g0 is being discarded, it has to also discard UNREF, as otherwise
> you would be left with a section in the executable that references an object
> that no longer exists.  With GOLD, since g0 exists, the UNREF section can be
> kept.  (By default unallocated sections are kept since they do not
> contribute anything to the runtime memory usage of the executable, and they
> can be presumed to contain something useful).
> 
>   So that is the situation.  Nothing has changed with 2.26 or the mainline
> sources by the way - they still behave in the way that you saw.
> 
>   To be honest however I do not think that there is a bug here to be fixed. 
> The fact that an unallocated, unloaded, non-debug section references data in
> the executable is very strange.  Or at least pretty unusual.  There are ways
> around the problem - by making the unref'ed section a note section or a fake
> debug section - but as far as I can see the only real issue is that LD and
> GOLD differ in their handling of the situation.  I don't believe that there
> is a standard that specifies what should happen in this situation, so either
> choice is valid.  You pick the linker that gives you the behaviour you want.
> 
>   Does that satisfy you ?
> 
> Cheers
>   Nick

Nick, thanks for the detailed explanation. However I do think ld's behavior is
not correct here. Should linker first decide if some sections are 'root'
sections that should not be throw away and then decide if other sections should
be GCed? Here linker first prunes the references and then is forced to discard
section not because it should do so, but to make the link succeed.

Other than gold, the linker for Mach-O also does not throw away unknown
sections it does know about.

As a result of the ld behavior, I did what hj suggested by making the section a
note section, and ld behaves as expected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.