[PATCH] D59780: Support Intel Control-flow Enforcement Technology

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 28 20:33:19 PDT 2019

MaskRay added a comment.

In D59780#1520436 <https://reviews.llvm.org/D59780#1520436>, @xiangzhangllvm wrote:

> In D59780#1520411 <https://reviews.llvm.org/D59780#1520411>, @MaskRay wrote:
> > In D59780#1520390 <https://reviews.llvm.org/D59780#1520390>, @xiangzhangllvm wrote:
> >
> > > I'm sorry, I reflect the problem to some leaders and experts, but the PLT ABI is still undecided. The most concern come from the unknow risk of difference with GNU.
> >
> >
> > @xiangzhangllvm If it is still undecided, then there is still opportunity to fix :) IMHO tooling is still immature and currently very few tools understand `.plt.sec`.
> >
> > I'd really like to see more discussions about this, e.g. https://groups.google.com/forum/#!topic/x86-64-abi/Z6GqQDy_NaI
> >  If PLT entries should be aligned by 16 to maximize performance, shall we switch to 32-byte PLT entry? Xiang, can you raise a topic on https://sourceware.org/ml/gnu-gabi/2019-q2 or https://sourceware.org/ml/binutils/2019-05/
> hi, fangrui, 32-byte PLT entry is also aligned by 16, I have test the performance before, they are same.

Great. If the unified 32-byte PLT entry scheme doesn't regress, let's delete `.plt.sec` and fix the ABI. I guess you are in a good position to do this. You may send an email to the gnu-gabi and binutils mailing lists.

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list