SHF_LINK_ORDER's original semantics make upgrade difficult

[Fangrui Song]

On 2020-07-16, Fangrui Song wrote:
>If I understand correctly, linkers support GRP_COMDAT but not other values. So
>you are right that we can make use of other values if we want to do some fancy
>things.
>
>In practice, I guess one reason people want to mess with a section flag is that
>adding a .group has non-trivial cost (sizeof(Elf64_Shdr)=64) if an object file
>may have many of them (especially when -ffunction-sections is enabled).
>
>For example, I added -fpatchable-function-entry=N[,M] in clang for the Linux
>kernel. Every .text section has an accompanying __patchable_function_entries
>with SHF_LINK_ORDER set. If I want to express this with a section group, I need
>to add a .group (SHT_GROUP) for each .text, the cost will go up from double to
>triple.
>
>>>On 7/16/20 1:27 AM, James Henderson wrote:
>>>Whilst doing this, I couldn't help but feel that the 
>>>associated-with and ordering semantics are somewhat orthoganol.
>
>Yeah, I am a big fan of non-orthogonality.. However, a gABI section flag seems a
>no-go now.
>
>>If the GNU linkers were modified to allow both ordered and
>>non-ordered sections, then I think you could use GROUP for
>>associating, and SHF_LINK_ORDER for actual ordering, where
>>that is desired. We probably don't need a third mechanism,
>>do we?
>
>This solution is acceptable. I will do this for LLD
>(https://reviews.llvm.org/D72904 ). We need an assembler syntax for
>(SHF_LINK_ORDER & sh_link=0).
>
>I created  https://sourceware.org/bugzilla/show_bug.cgi?id=26253 for a GNU as feature request.
>Peter Collingbourne proposed
>
>  .section .meta,"ao",@progbits,0
>
>I will expect that GNU as and LLVM integrated assembler match
>(probably https://reviews.llvm.org/D72899#2157020 )

Forgot to mention that there are two feature requests for ld and one for as.

* ld: A SHF_LINK_ORDER section with sh_link=0 is treated like a non-SHF_LINK_ORDER section.
   (sorry to send llvm links here: https://reviews.llvm.org/D72904
   but I hope the interested can get a bit more context from the links)

* ld: Arbitrary mix of SHF_LINK_ORDER and non-SHF_LINK_ORDER components
   within an output section is allowed.
   (https://reviews.llvm.org/D84001 )

   I just saw https://sourceware.org/bugzilla/show_bug.cgi?id=16833 after
   I had filed https://sourceware.org/bugzilla/show_bug.cgi?id=26256

   There is actually an interesting question about how we perform sorting
   with input section descriptions. My feeling is that sorting should be
   scoped within an input section description. See the links for more information.

* as: Support SHF_LINK_ORDER with sh_link=0
   https://sourceware.org/bugzilla/show_bug.cgi?id=26253
   (https://reviews.llvm.org/D72899 )

   There is actually an LLVM IR design issue requiring sh_link=0.
   Supporting this will help GNU ld and gold (if gold implements
   SHF_LINK_ORDER) with clang -flto (which requires LLVMgold.so )