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

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added inline comments.


================
Comment at: lld/ELF/Arch/X86.cpp:415
+namespace {
+class IntelCET : public X86 {
+  void writeGotPlt(uint8_t *Buf, const Symbol &S) const override;
----------------
ruiu wrote:
> MaskRay wrote:
> > `template <class ELFT> class IntelCET : public X86_64<ELFT> {`
> > 
> > `IBT-enabled PLT` can be used with the ILP32 programming model (x86-32 ABI). (If you don't like putting too much stuff in the initial commit, `class IntelCET : public X86_64<ELF64LE> {`.
> Actually the template is gone, I removed it because no code depended on ELFT. (Also no one really uses x32 ABI I guess? I thought that I read an article that Linux kernel developers are discussing deprecating x32 ABI.)
Sorry I didn't notice that X86_64 had been de-templated.


================
Comment at: lld/ELF/InputFiles.cpp:594
 
+// If a source file is compiled with x86 hardware-assisted call flow control
+// enabled, the generated object file contains feature flags indicating that
----------------
ruiu wrote:
> MaskRay wrote:
> > call flow control -> Control-Flow Enforcement ?
> This is a general name and not specific to the Intel's implementation.
My concern here is that llvm-objdump/GNU objdump and other tools/profilers would have to recognize two section names `.plt.sec` and `.splt`. Many tools use the section name to do special things, e.g.
@hjl.tools If the ABI can be changed to not deliberately differ from the implementation (or the other way round), it'd be great.

binutils/objdump.c:739 

```
static bfd_boolean
is_significant_symbol_name (const char * name)
{
  return strncmp (name, ".plt", 4) == 0 || strcmp (name, ".got") == 0;
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59780