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

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

I noticed that the latest GNU objdump can symbolize ld.bfd emitted .plt .plt.sec entries but not those emitted by lld. The gdb disassembly outputs exhibit the same difference.
I guess it is probably because lld doesn't emit the bnd prefix (0xf2) while ld.bfd does (BTW, I cannot turn off it: there is no `-z nobndplt`), and the relevant support isn't currently available in objdump.
If that is the case, it gives me the impression that the ABI can be changed as no tooling has caught up yet.

Since we don't emit the bnd prefix (0xf2) for MPX (MPX support has been dropped by GCC 9), we can merge `.plt` and `.plt.sec` entries as follows:

  4 endbr64
  5 jmpq *xxx(%rip) ; jump to the next endbr64 for lazy binding
  4 endbr64
  5 pushq           ; relocaton index
  5 jmpq *xxx(%rip) ; jump to .plt

This PLT entry takes 4+5+4+5+5=23 bytes. If we aim for an 8-byte alignment, we can get the 24-byte PLT entry size, which improves on the current 32-byte.
(However, if the bnd prefix is prepended to the jmpq instructions, the PLT will take 25 bytes and won't cram in a 24-byte entry. I feel people don't care much about it now, so don't let it pessimize common cases)

I have another question to @xiangzhangllvm: have you considered optimizing the PLT entry size for `-z now`? We can have such simple PLT entry:

  4 endbr64
  5 jmpq *xxx(%rip)

Of course, if we use `-z now`, there may be little reason not to just use `-fno-plt` when compiling the sources.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59780