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

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 23 15:16:31 PDT 2020


MaskRay added a comment.

In D76410#1937683 <https://reviews.llvm.org/D76410#1937683>, @pcc wrote:

> Having given this some more thought, I'm still not in favour of this change even with start/stop symbols excluded, since there are other cases where enumeration of SHF_LINK_ORDER sections may be possible/desirable. To give one example, imagine that you have `.init_array` sections linked to the globals that they initialize (this may be possible if you can prove that the constructor has no side effects other than initializing the object). With this change we may for example have multiple `.init_array` sections for `.bss` and `.data`, which would need to be accounted for when computing DT_INIT_ARRAY/DT_INIT_ARRAY_SZ. There are various ways that you could deal with this sort of situation, but it seems like the simplest one would be to stick with one output section per file.


I created the patch because I am not so fond of the relocatable check in D68094 <https://reviews.llvm.org/D68094>. The case you mentioned (SHF_LINK_ORDER .init_array) and .ARM.exidx are examples of a global singleton section. In such a use case, there is a global monolithic section that will be iterated by entry with a pair of symbols or a pair of dynamic tags. However, there is another set of non-singleton use cases. .stack_sizes is one of them.

> Given that the tool that deals with `.stack_size` sections has apparently been fixed, is there a need to make this change?

The immediate use case of this patch has been worked around. This patch is put up to discuss the most reasonable behavior.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76410





More information about the llvm-commits mailing list