SHF_LINK_ORDER's original semantics make upgrade difficult

[Fangrui Song]

> GNU ld: .gcc_except_table has both ordered [.foo' in a.o] and unordered [.foo' in b.o] sections

Correction: .foo has both ordered [`.foo' in a.o] and unordered [`.foo' in b.o] sections

(I was experimenting with SHF_LINK_ORDER .gcc_except_table . For this
discussion I just used a metasyntactic section name .foo but forgot to
replace all occurrences of .gcc_except_table)

On 2020-07-16, James Henderson wrote:
> I've run into this same problem whilst doing some prototyping work on
>fragmenting DWARF sections into smaller pieces. These pieces are a mixture
>of common pieces and function/variable-related pieces, with the latter
>being associated with the corresponding text/data sections via
>SHF_LINK_ORDER. However, in some cases, the section is laid out such that
>there are multiple common pieces intermixed with the
>function/variable-specific pieces (e.g. it might look like "common,
>function, function, common, function, variable, common"). I actually don't
>want this section to be ordered at all, since the original ordering should
>be preserved.I've been using a hacked LLD for this, which removes the
>ordering for SHF_LINK_ORDER completely, so that the sections remain in the
>"natural" order, whilst the associated-with semantics for --gc-sections are
>still preserved.
>
>Whilst doing this, I couldn't help but feel that the associated-with and
>ordering semantics are somewhat orthoganol. Clearly if a section is
>ordered, it needs the associated-with semantics, but it seems like section
>association is a different thing. There are multiple sections now where the
>ordering is irrelevant, but which still wants association in some way.
>Examples include LLVM's stack sizes section and debug data.The original
>SHF_LINK_ORDER extension discussion actually started out with discussing a
>SHF_ASSOCIATED flag. Maybe we should revisit that idea in some form? Thus,
>SHF_ASSOCIATED implies the section should be discarded when it's linked
>section is discarded, and SHF_LINK_ORDER requires ordering. I think both
>for backwards-compatibility's sake and to avoid redundancy, we could say
>SHF_LINK_ORDER implies SHF_ASSOCIATED.

I am in favor of a new section flag SHF_ASSOCIATED as well. We can use
the next bit:

#define SHF_ASSOCIATED 0x1000

In the assembler, assign it a .section flag 'm', e.g.

     .section __patchable_function_entries,"am",@progbits,foo
     # Create a __patchable_function_entries section with the SHF_ASSOCIATED flag
     # and sh_link referencing the section defining 'foo'

Unfortunately we will have a binutils release (2.35) with SHF_LINK_ORDER
syntax (.section flag 'o')
https://sourceware.org/bugzilla/show_bug.cgi?id=24526
Unless we could be really quick and fix it, we might have to let SHF_LINK_ORDER
imply SHF_ASSOCIATED permanently.
(On the LLVM side, I think we could keep LLD's SHF_LINK_ORDER implying SHF_ASSOCIATED
for one or two releases and then drop that)


SHF_ASSOCIATED

     SHF_ASSOCIATED indicates that the section contains metadata describing
     the referenced section.  When performing unused section elimination, the
     link editor should ensure that both the section and the referenced
     section are retained or discarded together. Furthermore, relocations
     from this section into the referenced section should not be taken as
     evidence that the referenced section should be retained.