[PATCH] D75181: [AArch64] Handle BTI/PAC in case of generated functions.
Daniel Kiss via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Wed Apr 8 14:08:34 PDT 2020
danielkiss 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");
----------------
tamas.petz wrote:
> 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")))?
Chill: I think I have code that solve that for clang created functions, but functions created in llvm I don't have any idea.
Tamas: yes, that is the case when module is compiled with bti but the function is not ( "none" or "pac-ret" and so on. )
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D75181/new/
https://reviews.llvm.org/D75181
More information about the cfe-commits
mailing list