linker script, /DISCARD/ section and SHT_GROUP

[Fangrui Song]

On 2019-11-21, Nick Clifton wrote:
>Hi Fanguri, Hi Alan,
>
>  OK, so what do you think of this small patch which just updates
>  the linker documentation:
>
>diff --git a/ld/ld.texi b/ld/ld.texi
>index 3b2d05411f..ed538fbfe2 100644
>--- a/ld/ld.texi
>+++ b/ld/ld.texi
>@@ -4994,6 +4994,11 @@ The special output section name @samp{/DISCARD/} may be used to discard
> input sections.  Any input sections which are assigned to an output
> section named @samp{/DISCARD/} are not included in the output file.
>
>+Note, sections that match the @samp{/DISCARD/} output section will be
>+discarded even if they are in an ELF section group which has other
>+members which are not being discarded.  This is deliberate.
>+Discarding takes precedence over grouping.
>+
> @node Output Section Attributes
> @subsection Output Section Attributes
> @cindex output section attributes

The comment update looks good to me.

>> 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
>
>Yes, this is on my list, although I was hoping that somebody else would
>take the lead on it.  I will try to find some tine for it next week.

Great. Thanks! This SHF_LINK_ORDER may be seen as a generalization of
the special .ARM.exidx* (which has a sh_link field referencing the
associated text section) rule.

I know at least one sanitizer feature (clang
-fsanitize-coverage=trace-pc-guard) that requires the SHF_LINK_ORDER
semantics. SHF_LINK_ORDER is used as a lightweight section group with a
unidirectional relation: which has the special garbage collection
semantics but does not require an additional section .group

The promising examples may be .debug_info.* and Annobin .note.*
In the future, when such section metadata is used more, SHF_LINK_ORDER
instead of SHT_GROUP can decrease code sizes.