[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