[PATCH] D59780: Support Intel Control-flow Enforcement Technology
Fangrui Song via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Dec 11 19:46:37 PST 2019
MaskRay added a comment.
In D59780#1779860 <https://reviews.llvm.org/D59780#1779860>, @andrew.w.kaylor wrote:
> In D59780#1778882 <https://reviews.llvm.org/D59780#1778882>, @tstellar wrote:
>
> > In D59780#1778863 <https://reviews.llvm.org/D59780#1778863>, @ruiu wrote:
> >
> > > Hmm, I'm sorry but I'm confused. IIRC I had a discussion in the LLVM dev meeting that we were going to submit a change with a single PLT scheme rather than IPLT, so when I said that I'm going to submit a patch, I meant that I'm going to submit a patch for the 1PLT scheme rather than the 2PLT scheme. But this is for the 2PLT scheme. This is not something I want.
> >
> >
> > What was the decision that was made at the developer meeting? Will lld support the 2PLT scheme defined in the psABI?
>
>
> I don't know what was discussed at the developer meeting, but I don't see how not following the established ABI is an option. It seems clear that GNU implementations will not change the ABI they've been using for 2+ years. I don't see the value in having lld create a competing ABI.
The PLT scheme in this patch is already different. See that GNU ld -z ibt produces a MPX bnd prefix but this patch doesn't. Also check out my objdump (built from HEAD) example above. PLT schemes have already diverged. I am still not very convinced doing things differently is breaking ABI. If pursing for 1PLT scheme breaks ABI, then this patch breaks ABI, too.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59780/new/
https://reviews.llvm.org/D59780
More information about the llvm-commits
mailing list