[llvm-dev] [lld] RFC: Allow custom sections to be under GNU_RELRO

[Fangrui Song via llvm-dev]

On 2020-03-30, Peter Smith via llvm-dev wrote:
>>> This can be important in large programs compiled -ffunction-sections as there can be millions of sections to match.
>> I understand the reason of having these conventions in linkers. On the other hand, there already exists a format with the fixed ".rel.ro" suffix for
>> .data and .bss. Custom suffixes would also mean that the user code would depend more on implementation-specific things, i.e. prefixes. For
>> example, one would wonder, should they annotate their data with __attribute__((section(...))) for ".data.rel.ro.my_section" or
>> ".bss.rel.ro.my_section"?
>
>The way that they are implemented the .data.rel.ro and the .bss.rel.ro are 2 separate prefixes, rather than having a single shared .rel.ro suffix, infix even if we are counting .data.rel.ro.* and .bss.rel.ro.*
>
>Having prefixes and suffices being significant could also lead to situations where we have a recognised prefix and a recognised suffix on the same selector. I suspect that for most use cases this won't happen but the tools ought to guard against it which does require more complexity.
>Anyhow, that's just my opinion on the use of a suffix, there may be others without my concerns.

This may require some logic in GNU ld's orphan section placement, which
may be more difficult given that it is linker script driven. gold and
lld may implement such rules more easily, but I am just speculating.

>Given a clean slate, I'd try and do this via a section flag. If all Input Sections in an OutputSection have the  SHF_RELRO flag then the Section is SHF_RELRO, this isn't ideal for a flag as we have to actively clear it if there is a mix of SHF_RELRO and non SHF_RELRO, but it would at least solve the naming problem. The difficulty here is getting support for a new ELF Section flag across ELF toolchains.

Florian Weimer also mentioned we can use a new section flag
https://sourceware.org/pipermail/binutils/2020-March/110428.html

FWIW, some people expressed willingness to maintain ELF spec again
(unmaintained since ~2015)
https://groups.google.com/forum/#!topic/generic-abi/cfOCv5Y0-B4

Non-GNU perspecitives will be nice:)

>>> In principle, if you can get a convention agreed by the ELF linkers then I don't see too much of a problem.
>> LLD is the primary linker we use for the most of the platforms we officially support. I wonder, would lld folks be happy if this feature is first
>> implemented as an lld extension and then ported to other linkers as well?
>
>Personally I'd prefer trying to come up with a solution in both communities first. There is a danger that one community won't accept an extension that they haven't been involved in the design process for. There are some efforts such as https://www.openwall.com/lists/libc-coord/2020/01/30/1 set up to try and do more cross community design. Again this is just my opinion, I can't claim to speak for all of the LLD developers.

+1 for a topic on libc-coord