[PATCH] D75181: [AArch64] Handle BTI/PAC in case of generated functions.

Tamas Petz via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Apr 7 10:50:47 PDT 2020


tamas.petz added inline comments.


================
Comment at: clang/lib/CodeGen/TargetInfo.cpp:5149-5152
+          if (BPI.BranchTargetEnforcement)
+            Fn->addFnAttr("branch-target-enforcement", "true");
+          else
+            Fn->addFnAttr("branch-target-enforcement", "false");
----------------
chill wrote:
> danielkiss wrote:
> > I'm going to rebase the patch. I add there a new attribute here "ignore-branch-target-enforcement"
> > so then the "branch-target-enforcement"="true"/"false" could be just "branch-target-enforcement".
> > 
> > 
> TBH, that's worse, IMHO.
> 
> Ideally, I *think* we'd like *every* LLVM IR function that the backend sees,
> regardless of how, why and by whom it is created, to have (or not have)
> the three existing PACBTI attributes "sign-return-address", "sign-return-address-key", and "branch-target-enforcement", so the backend can generate code accordingly.
> 
> The module attributes are LLVM IR metadata,  and  AFAIK LLVM IR metadata is an optional extra, 
> it should not affect correctness.
> Indeed, *module* metadata is a somwhat grey area,  better not use it if there a way around it.
> 
> 
> 
Which case are you trying to handle here?
Is this the case, for example, when -mbranch-protection=standard is set but a function has _attribute _((target("branch-protection=none")))?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75181/new/

https://reviews.llvm.org/D75181





More information about the cfe-commits mailing list