[llvm] [AArch64][Docs] Add release note for execute-only support on AArch64 (PR #134799)

Csanád Hajdú via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 10 02:20:15 PDT 2025


Il-Capitano wrote:

> Is there a description somewhere of why you're implementing this? Last time we looked at this, we concluded it wasn't really useful. See https://reviews.llvm.org/D48791 .

I'm not sure if there's a description of the reason why this is necessary, so I'll summarize it here:

The solution that was arrived at the last time assumes that all generated code for AArch64 can be marked execute-only. However this approach has an issue with `-fsanitize=function` (which is a part of `-fsanitize=undefined` by default), which does a signature check on indirect function calls by reading two 4-byte words in front of the called function's address, causing a segmentation fault when running in execute-only mode. It seems `-fsanitize=function` was enabled in Clang 17 for AArch64 ([godbolt](https://godbolt.org/z/dqcavezj3)), about 5 years after the initial patch you linked, so it's a fairly recent problem.

Providing a Clang font-end option (`-mexecute-only`/`-mpure-code`, used for ARM already) is necessary to diagnose this incompatibility between `-fsanitize=function` and execute-only code, and the linker needs to be able to deal with linking mismatched object files. The solution I've been implementing is based on the ARM backend's use of the `SHF_ARM_PURECODE` ELF section flag to indicate the execute-only-compatible property. A similar section flag was added to the AArch64 ELF ABI recently (https://github.com/ARM-software/abi-aa/pull/304) to enable this work.

The reason why this work was started is to try to turn execute-only memory back on in Android.

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


More information about the llvm-commits mailing list