bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/19446] BFD linker discards section without alloc section a


From: nickc at redhat dot com
Subject: [Bug binutils/19446] BFD linker discards section without alloc section attribute under certain conditions
Date: Thu, 21 Jan 2016 16:35:14 +0000

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

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at redhat dot com

--- Comment #8 from Nick Clifton <nickc at redhat dot com> ---
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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]