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

Tue Apr 16 07:23:30 PDT 2019

MaskRay added a comment.

> Red Hat Enterprise Linux 8 Beta (publicly available for x86_64) is using the current CET PLT layout generated by BFD.

If it uses MPX and the `bnd` prefix, it is probably not too late to change.

> To change the ABI you must go upstream to the ABI discussion list and have that discussion with the hardware vendor. The hardware vendor supports many different operating systems and implementations and the changes to the standard need to be discussed there. Alternatively you can make and adhere to your own standards and work with downstream tooling to support those standards as alternative implementations (hopefully with interoperability). I would not like to see two alternative ABIs, that leads to serious problems in downstream tooling and duplicated effort.
> 
> My opinion is that lld is too late to make the requested change to the PLT format at this point. You either get to adhere to the standard and participate in distribution builds, or not and you don't.

@codonell @xiangzhangllvm I did create a thread in the x86-64-abi mailing list https://groups.google.com/forum/#!topic/x86-64-abi/Z6GqQDy_NaI The only reply was from the maintainer. I think I'd like **more opinions from others**.

I am a happy Linux glibc user but I want to learn things from multiple perspectives - insights from other parties are good. So I asked some FreeBSD folks to chime in and I asked how musl people felt about the second PLT scheme. Since this second PLT is really Linux+x86+glibc lazybind specific - it implies more overhead to other libcs. musl people can probably live with `-fno-plt` (musl doesn't support glibc style lazybind - they don't need PLT at all)

To be honest I feel the ABI is proposed in such a way that enforces other OSes, linkers, binary manipulation tools, emulators, diassemblers, binary analyzers, instrumentation tools and profilers to follow suit: **there are announcements but no design discussions**. However, I know at this point arguing is probably unavailing.  Therefore, I believe I can be convinced if someone (from Intel, Red Hat, etc) **gives performance numbers demonstrating this second PLT scheme has indeed the cache-locality merit and is better than the alternative 24-byte PLT entry scheme**.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59780