linker script, /DISCARD/ section and SHT_GROUP

[Fangrui Song]

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