Page MenuHomePhabricator

[AArch64] Implement execute-only CodeGen Support.

Authored by ivanlozano on Jun 29 2018, 2:43 PM.



This implements execute-only support for AArch64 targets, similar to the ARM code generation for execute-only.

Diff Detail

Event Timeline

ivanlozano created this revision.Jun 29 2018, 2:43 PM

This is really cool. I just had one minor suggestion for testing, and will otherwise defer to the ARM64-related folks to accept the patch. The rest looks quite reasonable to me, though.


Does it make sense to have another test that runs llvm-readobj on an assembled object and verifies that these sections are indeed marked as execute-only?

srhines added inline comments.Jun 29 2018, 3:09 PM

And I just realized that the corresponding llvm repository change has exactly that test. Sorry for the noise.

ivanlozano marked 2 inline comments as done.Jun 29 2018, 3:16 PM
ivanlozano added inline comments.

No problem!

It looks like this patch does two things:

  1. Adds MC layer support for the SHF_ARM_PURECODE flag on AArch64.
  2. Adds the AArch64 SHF_ARM_PURECODE flag to all sections containing code if the "execute-only" subtarget feature is enabled.

I guess nothing else is necessary because the AArch64 backend doesn't generate inline constant pools anyway?

What happens if the input IR has a mix of execute-only and non-execute-only functions? Does the output .text section have the SHF_ARM_PURECODE flag?

ivanlozano marked an inline comment as done.Jun 29 2018, 4:29 PM

What happens if the input IR has a mix of execute-only and non-execute-only functions? Does the output .text section have the SHF_ARM_PURECODE flag?

All sections that go into the final combined .text in a binary need to have the SHF_ARM_PURECODE flag set, otherwise the flag gets removed by the linker. D48795 adds this behavior for AArch64 to LLD.

No, I meant, what happens if two functions in the same IR module have different execute-only settings?

Passed an IR file to llc with a mix of functions that have the execute-only attribute set and ones that don't to test this. Two .text sections are generated in the object file, one with the SHF_ARM_PURECODE flag set and one without, and functions reside in their respective sections.

There is an ABI issue with using an Arm specific flag that isn't defined in AArch64. I've not had a chance to check over the code yet, but will try to do so later today.


SHF_ARM_PURECODE is defined in the Processor specific part of ELF Section flags (SHF_MASKPROC [1]) it is only defined for Arm (see SHF_NOREAD) [2] and is not currently defined for AArch64. If we use it here we risk the ABI using the same flag for something else and we will have a binary compatibility problem.

In practice I think that it would make sense to define SHF_AARCH64_PURECODE with the same value. I will raise an issue with the AArch64 ABI, it would be good to get at least some indication that this value will be reserved so that we can use it.

[1] Generic ELF Spec
[2] ELF for the Arm Architecture
[3] ELF for the Arm 64-bit Architecture

Some early feedback from the AArch64 ABI along the lines of "Do you actually need SHF_AARCH64_PURECODE?" In Arm there has been a long history of using literal pools so it is important to mark code that has been compiled to avoid them as SHF_ARM_PURECODE. In AArch64 the expectation is that code is execute-only unless someone has forced it otherwise. An alternative model is to assume that all executable sections are implicitly execute-only and therefore all that you would need is an option at link time to remove PF_R from a program header that contained only executable sections. In essence we can have a one time declare all executable sections as execute-only at link time. I think that this would be compatible with adding SHF_AARCH64_PURECODE later if there was a code-generation model that made use of literal pools.

This seems reasonable to me. I'll look into putting together an LLD patch that does this. Thanks!

ivanlozano abandoned this revision.Jul 30 2018, 10:17 AM

Alternative solution committed: rL338271