[clang] [llvm] [Clang][AArch64] Command-line options for A-profile's Sign Return Address Hardening (PR #176171)
Anatoly Trosinenko via cfe-commits
cfe-commits at lists.llvm.org
Tue Sep 8 12:06:50 PDT 2026
================
@@ -226,6 +227,15 @@ void TargetCodeGenInfo::setBranchProtectionFnAttributes(
F.removeFnAttr("sign-return-address-key");
}
+ if (BPI.SignReturnAddressHardening ==
+ LangOptions::SignReturnAddressHardeningKind::None) {
+ F.removeFnAttr("sign-return-address-harden");
+ } else if (BPI.SignReturnAddr !=
+ LangOptions::SignReturnAddressScopeKind::None) {
+ F.addFnAttr("sign-return-address-harden",
+ BPI.getSignReturnAddressHardeningStr());
+ }
----------------
atrosinenko wrote:
I wonder if an easier approach can be used (same as in `initBranchProtectionFnAttributes`):
* if `BPI.SignReturnAddressHardening` **is** None, remove the attribute
* if `BPI.SignReturnAddressHardening` **is not** None, set the attribute
Alternatively, if it is important to never set "sign-return-address-harden" function attribute without the "sign-return-address" attribute (and at the same time we cannot rely on this invariant holding for `BPI` for some reason), then the existing approach lacks the final `else` branch containing one more `removeFnAttr`. The `initBranchProtectionFnAttributes` should probably be updated then as well.
PS: Strictly speaking, the other calls to `removeFnAttr` in this function are performed after checking if the attribute exists with `hasFnAttribute`. On the other hand, it looks like `removeFnAttr` checks this by itself down the stack, so maybe these are the *other* calls to `removeFnAttr` that have to be simplified someday later...
https://github.com/llvm/llvm-project/pull/176171
More information about the cfe-commits
mailing list