[PATCH] D74006: [MC][ELF] Make linked-to symbol name part of ELFSectionKey

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D74006#1859875 <https://reviews.llvm.org/D74006#1859875>, @peter.smith wrote:

> > This is a deliberate choice so that we don't need to know the section where foo and bar are defined beforehand.
>
> Just want to make sure this is well defined with respect to the description in ELF.
>
>   SHF_LINK_ORDER
>        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.
>  
>   A typical use of this flag is to build a table that references text or data sections in address order. 
>
>
> If we have two sections S1, S2, with a SHF_LINK_ORDER on the same section D, what is their ordering relationship between S1 and S2? If foo and bar are in the same section and we don't create two sections then we don't get this problem as we'd only have one S with a sh_link to D. I think that if the author is trying to use SHF_LINK_ORDER to build a table that references text or data sections in address order then they may get surprised if S1 and S2 are not in the order of foo and bar. True that if one section where generated they'd have to ensure that the contents of S where in the same relative order to foo and bar in D but at least they would know the linker couldn't alter it.


"Two sections with the same sh_link" this scenario is probably not clearly specified. I will expect a stable sort by sh_link. For the following part of the added test, after linking,

  .section .foo,"o", at progbits,foo  # first in the output section .foo due to stable sort
  .byte 0
  
  .section .foo,"o", at progbits,bar  # second
  .byte 1

This is what lld currently does. It will be nice to get a sign-up from GNU ld. An alternative choice is that users should not rely on the order. I'm inclined to define an order here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74006