[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.

Given the somewhat loose definition in ELF

  This flag adds special ordering requirements for link editors. The requirements apply if the sh_link field of this section's header references another section (the linked-to section). If this section is combined with other sections in the output file, it must appear in the same relative order with respect to those sections, as the linked-to section appears with respect to sections the linked-to section is combined with.
  NOTE: A typical use of this flag is to build a table that references text or data sections in address order.

In the text below, a generic SHF_LINK_ORDER section is just a section we haven't identified as needing any special requirements and only demands what it is written in the ELF spec. A non-generic SHF_LINK_ORDER section like .ARM.exidx has additional requirements on top of generic ELF, for example from the ARM ABI documentation.

There are no requirements for a generic SHF_LINK_ORDER section to be combined together in one section or split apart depending on whether the linked-to sections are in different OutputSections. So not merging SHF_LINK_ORDER sections is as good as merging them. Other linkers may choose to handle them differently. So in principle no objections, however I'm not sure we should consider the .stack_size sections as generic SHF_LINK_ORDER sections as from the PR they seem to rely on having a single .stack_size OutputSection per sh_link to OutputSection they describe, this is an opposite requirement for .ARM.exidx, which requires a single contiguous table (normally implemented as a single OutputSection), but as it is processed at run-time there are requirements on the section level view. Can we make an arbitrary decision on all future SHF_LINK_ORDER sections for the benefit of .stack_size?

For the linker script case for generic SHF_LINK_ORDER sections I think we have to respect what is written in the linker script on the grounds that the user knows their own requirements and wrote the linker script accordingly. I think that this might make writing a linker script using .stack_size sections and multiple output sections pretty much impractical for some cases. Perhaps another reason to treat .stack_size sections separately like .ARM.exidx, although .ARM.exidx is pretty easy to write a linker script for.

So in principle no objection, but I recommend handling .stack_sizes as a special case, especially for linker scripts if they have special requirements above what is written in ELF.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76410