[lld] [LLD][AArch64] Mark .plt with PURECODE flag if all input sections also have it (PR #132224)

[Peter Smith via llvm-commits]

=?utf-8?q?Csanád_Hajdú?= <csanad.hajdu at arm.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/132224 at github.com>


================
@@ -2610,6 +2610,18 @@ PltSection::PltSection(Ctx &ctx)
   // modify the instructions in the PLT entries.
   if (ctx.arg.emachine == EM_SPARCV9)
     this->flags |= SHF_WRITE;
+
----------------
smithp35 wrote:

Apologies for the long comment!

It is possible to find the OutputSection that contains the .plt, it would be something like `.in.plt->parent`. That would mean that we would only need to check OutputSections rather than input sections. If the .plt is mixed with non XO InputSections then the OutputSection is in will be non-XO. However ... 

Taking a step back, I think it will be worth thinking through what the heuristics for Program Header generation are when it comes to XO. Apologies I didn't have time to write this up yesterday Evening. I think there could be more than just the `.plt` that is affected. 

In principle any orphan section with SHF_PURECODE (that generates an OutputSection) will propagate SHF_PURECODE to the OutputSection, which  is going to auto-generate an XO program header on a transition from non-XO, which isn't going to be helpful for a non-XO program. How much of a problem this is I don't know. For an Android/Linux system needing full XO, there may be a non-zero number of libraries that need SHF_PURECODE just in case they are used in an XO context. In a contrived worst case we have alternate XO, non-XO output sections and get a separate program header for each OutputSection.

Thinking of a model for how this would be used, I think we have two (possibly three) cases:
* Bare-metal system (how XO is currently used on Arm), no PLT, no dynamic linking, linker script, potential mix of XO (my code) and non XO (library code).
* An OS that can support all XO or non-XO for a particular program, PLT highly likely, default linker script, dynamic linking. I'm guessing this is where Android will be heading.
* An OS that can support separate parts of the program being XO and non-XO (presumably separated by a page boundary). I don't think that anyone needs/wants this level of flexibility.

For the bare-metal system we would like to have separate XO and non-XO program headers for the same output file. It is up to the user to write the linker script to separate out the XO and non-XO into distinct memory regions, and possibly use PHDRS to make sure they get what they need.

For the OS that can only have a program thats XO or not XO, we ideally want all executable OutputSections to be XO before generating an XO program header.

For the OS that can have multiple XO and non XO parts, then there's no good simple heuristic that I can think of that's always going to work. However I think we can probably rule this use case out.

With that in mind I propose that we do something like:
* Unconditionally add SHF_PURECODE to the .plt.
* For a program using an OS (defined as having a dynamic section, or a PLT), then when auto generating program headers (no linker script PHDRS), then clear SHF_PURECODE from all executable OutputSections if at least on executable OutputSection is not XO.
* Leave behaviour as it is for bare-metal programs (that don't have a PLT or dynamic section).

Not sure I've got that completely right, but it should be close. I think that could be applied in createPhdrs().

The alternative view is that this is too complicated and it is only the PLT that the linker should care about, getting XO right is the users responsibility.

In that case it may simplify to
* Unconditionally add SHF_PURECODE to the .plt
* If at least one executable OutputSection has non-XO, then find the OutputSection containing the PLT (.in.plt->parent) and clear SHF_PURECODE from that OutputSection.

Again this could be done at the start of createPhdrs().



https://github.com/llvm/llvm-project/pull/132224