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: linker script, /DISCARD/ section and SHT_GROUP


On 2019-11-20, Alan Modra wrote:
On Tue, Nov 19, 2019 at 01:49:22PM +0000, Nick Clifton wrote:
Hi Guys,

> I don't see anything particularly strange.  A section group typically
> is used to package up code, data and debug info for a function.  You
> normally want to include or exclude the whole group, but in some cases
> you might want to exclude all sections of a particular type.  An
> obvious example is when stripping debug info.  Other abnormal cases
> surely exist, allowed for by /DISCARD/.

The problem is that discarding sections in this way breaks the semantics
of the ELF section group, so at the very least we ought to document this
behaviour.

I disagree, and I think the ELF spec is wrong to say "such groups must
be included or omitted from the linked object as a unit".  Or at
least, interpreting the wording strictly is wrong.  The example I gave
of a linker omitting all debug sections is an obvious exception to the
rule.  It would make no sense *at all* for debug info in groups to be
kept when other debug info was dropped.

I agree with Alan in that we should take the ELF spec explanation with a
grain of salt because it was written without taking --gc-sections into
consideration. My understanding was explained in a previous reply
https://sourceware.org/ml/binutils/2019-11/msg00210.html

Attached however is a proposed patch to change the linker's behaviour so
that it would behave in the following way:

  * If a /DISCARD/ed section is not part of an ELF group, then always
    discard it, just like before.

  * Otherwise if any of the other sections in the group are the subject
    of a KEEP directive, then treat the section as an orphan.  (I did not
    want to reparse the linker script to see if the section matched some
    other section directive).  This will usually mean that the section will
    be retained, unless orphans are being discarded.

I think this is a horrible complication that serves no useful
purpose, and would probably break things that now work.  I'm sorry
that being away I didn't see the original email earlier to try to
dissuade you from writing the patch.

  * Otherwise discard the section as normal.

  * If the --verbose linker option is in effect then generate information
    messages when then /DISCARD/ section interacts with an ELF group.

/DISCARD/ is dangerous.  It's for people who know what they're doing.
Why single out groups for a nanny message?

Say, .text.foo and .debug_info.foo are in the same section group.
This means two things

* If .text.foo is kept, .debug_info.foo should also be kept, otherwise
 there will be some loss of debuggability.
* If .debug_info.foo is kept, .text.foo should also be kept, otherwise
 there will be redundant metadata.

When the user specifies /DISCARD/ : {*(.debug_info.*)} in a linker script,
they explicitly opt out the first relation.

FYI, I pushed a commit to lld earlier today
https://reviews.llvm.org/D70146 (will be included in lld 10).  It
implemented the GNU ld behaviors I observed.


Now that we started to discuss garbage collection. Please allow me to
start a related topic about SHF_LINK_ORDER, see
https://sourceware.org/ml/binutils/2019-11/msg00266.html


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