[PATCH] D72222: [Driver][CodeGen] Add -fpatchable-function-entry=N[,0]

Fri Jan 24 08:50:03 PST 2020

mrutland added a comment.

In D72222#1837536 <https://reviews.llvm.org/D72222#1837536>, @MaskRay wrote:

>

> For `BTI c` issue, GCC has several releases that do not work with -mbranch-protection=bti. The Linux kernel has to develop some mechanism to detect the undesirable placement of `bti c`, if there are -mbranch-protection=bti users. So I don't think that inconsistency in clang 10.0.0 with GCC will be a problem.

Speaking as the person implementing the Linux side of things, I think that will be a problem. Kernel-side we want consistency across compilers.

For Linux we were planning to do a very simple build-time test to rule out compilers with the broken behaviour. We would expect functional compilers to have a consistent layout for a given combination of options, and we would consider this layout to be ABI.

The compile time check would compile a trivial test file, e.g.

  void function(void) { }

... with flags:

  -fpatchable-function-entry=2 -mbranch-protection=bti

... and if the function entry point is a NOP, mark that compiler as broken. In practice, this will mean that the kernel build system will disable BTI support for those broken compilers.

Trying to support different layout approaches within Linux will add a fair amount of unnecessary complexity which we cannot contain in one place, and makes it more likely that support for either case will be broken in future.

For the M=0 case, I would prefer to avoid runtime detection unless really necessary.

For the M!=0 case, which I believe Linux will need to use in the near future, I realise that a runtime check will be necessary to detect the absence of a BTI. Regardless, consistent behaviour across compilers will make this significantly simpler and less error-prone.

Thanks,
Mark.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72222