[PATCH] D76410: [ELF] Don't combine SHF_LINK_ORDER sections linking different output sections

[Peter Smith via Phabricator via llvm-commits]

psmith added a comment.

Thinking  about this a bit more, this is my opinion.

I think anyone that designs a section type with special ordering or collation requirements that wants it to be portable across as many linkers, without custom processing, will need to make it drop out of standard ELF and existing convention. From memory .ARM.exidx was designed to follow the ELF Rules for Linking Unrecognized Sections quoted at the end, albeit with a couple of caveats:

- Some assemblers didn't support having multiple sections with the same name so .ARM.exidx.<section name> was needed when each function was output in its own section.
- .ARM.exidx is a processor specific type rather than OS-specific type.

By following the the Unrecognized Sections and .ARM.exidx and .ARM.exidx.* naming convention it made it fairly easy to collate all the sections in one place. Having one section makes a derived __start and __stop unique.

If we are apply these rules to LLVM stack-size then it should have its own OS-specific type or flag so that the rules for linking unrecognized sections apply, and it should have a distinct name derived from the orphan name of the code section it has a sh_link to. This will also produce uniquely named derived __start and __stop symbols that can be referred to, and it permits linker scripts to be written to match the names. If that sounds fragile then I agree. I'm not sure that it is realistic to design a SHF_LINK_ORDER section that relies on the sh_link field in the executable without needing special linker support.

>From this I think we don't need to treat SHF_LINK_ORDER in non-relocatable links specially. If something like LLVM stack size section comes along we should treat it specially as I don't think it can be easily handled generically.

I think relocatable links mess this argument up as they really are a special case not really covered by ELF at all. If they were to be purely relocatable the linker would do no collation at all, but kernel module require collation as they are using them as a form of dynamic linking. So I think our current behaviour for these is fine.

  Rules for Linking Unrecognized Sections
  If a link editor encounters sections whose headers contain OS-specific values it does not recognize in the sh_type or sh_flags fields, the link editor should combine those sections as described below.
  If the section's sh_flags bits include the attribute SHF_OS_NONCONFORMING, then the section requires special knowledge to be correctly processed, and the link editor should reject the object containing the section with an error.
  
  Unrecognized sections that do not have the SHF_OS_NONCONFORMING attribute, are combined in a two-phase process. As the link editor combines sections using this process, it must honor the alignment constraints of the input sections (asserted by the sh_addralign field), padding between sections with zero bytes, if necessary, and producing a combination with the maximum alignment constraint of its component input sections.
  
  - In the first phase, input sections that match in name, type and attribute flags should be concatenated into single sections. The concatenation order should satisfy the requirements of any known input section attributes (e.g, SHF_MERGE and SHF_LINK_ORDER). When not otherwise constrained, sections should be emitted in input order.
  - In the second phase, sections should be assigned to segments or other units based on their attribute flags. Sections of each particular unrecognized type should be assigned to the same unit unless prevented by incompatible flags, and within a unit, sections of the same unrecognized type should be placed together if possible.
  
  Non OS-specific processing (e.g. relocation) should be applied to unrecognized section types. An output section header table, if present, should contain entries for unknown sections. Any unrecognized section attribute flags should be removed.
  
  NOTE: It is recommended that link editors follow the same two-phase ordering approach described above when linking sections of known types. Padding between such sections may have values different from zero, where appropriate.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76410/new/

https://reviews.llvm.org/D76410