[PATCH] D72904: [ELF] Allow SHF_LINK_ORDER sections to have sh_link=0

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D72904#2165103 <https://reviews.llvm.org/D72904#2165103>, @pcc wrote:

> In D72904#2164880 <https://reviews.llvm.org/D72904#2164880>, @MaskRay wrote:
>
> > See also @jhenderson's latest reply to the generic-abi thread "SHF_LINK_ORDER's original semantics make upgrade difficult" <https://groups.google.com/forum/#!topic/generic-abi/hgx_m1aXqUo>
> >
> >   # input.o:
> >   <table header> [common]
> >   - DW_TAG_compile_unit [common]
> >   -- DW_TAG_variable [.data.foo]
> >   -- DW_TAG_namespace [common]
> >   --- DW_TAG_subprogram [.text.bar]
> >   --- DW_TAG_variable [.data.baz]
> >   <table footer> [common]
> >
> >
> > @pcc I sent the patches since you expressed a preference on more work on SHF_LINK_ORDER. Though, @jhenderson's needs (and my header/footer argument in that thread) make me think more whether we should continue patching SHF_LINK_ORDER or start pursuing another section flag.
> >
> > Without metadata sections's override, SHF_LINK_ORDER will have very few use cases. The problems still exist but we probably don't really need to address them.
>
>
> I think it is too premature to consider adding a section flag, since they are a limited resource. Furthermore, adding a flag whose absence means "use the linker's default input section ordering", and creating compiler features that rely on said default input section order, may constrain us in the future if we want to change the default order (consider features like ICF). Ideally, we would create a flag that means "instead of using the normal SHF_LINK_ORDER ordering, use this other ordering". But that would require specifying exactly what that means so that future linker changes don't break it.


I think the new flag would not have anything to do with ordering, and would be used for the depedency relationship currently specified by SHF_LINK_ORDER - thus a section could be associated with another section, but not want any reordering. That being said, as mentioned in the gABI thread, the group section approach might be better. Some brief experimentation I did yesterday suggested that fragmenting the DWARF had no significant performance impact, which might suggest that the additional section overhead of a group section is actually harmless. However, I have yet to verfiy either that idea, or my initial results.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72904