[lld] [LLD][ELF][AArch64] Add support for SHF_AARCH64_PURECODE ELF section flag (3/3) (PR #125689)

Peter Smith via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 17 10:40:38 PST 2025


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


================
@@ -2179,6 +2181,34 @@ template <class ELFT> void Writer<ELFT>::checkExecuteOnly() {
                             "data and code";
 }
 
+// Check that all input sections of .text have the SHF_AARCH64_PURECODE section
----------------
smithp35 wrote:

While I think this will work in a lot of cases, there can be multiple executable output sections covered by a PF_E program header.  It is true that the output of executable sections from the compiler will use a .text prefix and end up in the .text output section. However there can be named sections, and assembler sections that may not follow that convention. These will get placed as orphans and will get missed by this check.

What I think needs to happen is to find all OutputSections that are mapped to a program header that has the execute `PF_E` and read `PF_R` flag. There is no point in checking OutputSections that are mapped to a program header with `PF_E` and not `PF_R` as we already know all those sections are execute-only by construction.

When there's more than one program header with `PF_E` and `PF_R` it will be useful to logically group the output per program header. While in Android there will only be one executable program header, in bare-metal systems there can be more than one. It is also likely that in an embedded system some program headers are supposed to be execute-only and some not. In particular when a toolchain only has non-execute-only C and C++ libraries these need to be separated into their own program header.

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


More information about the llvm-commits mailing list