This implements execute-only support for AArch64 targets, similar to the ARM code generation for execute-only.
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?
It looks like this patch does two things:
- Adds MC layer support for the SHF_ARM_PURECODE flag on AArch64.
- 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?
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 ) it is only defined for Arm (see SHF_NOREAD)  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.
 Generic ELF Spec http://www.sco.com/developers/gabi/latest/ch4.sheader.html
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.