[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