[PATCH] D148034: [clang][driver] Disable GP relaxation with RISC-V ShadowCallStack

Thu Apr 13 06:00:25 PDT 2023

asb added a comment.

In D148034#4262991 <https://reviews.llvm.org/D148034#4262991>, @MaskRay wrote:

> In D148034#4260376 <https://reviews.llvm.org/D148034#4260376>, @asb wrote:
>
>> Will `--[no-]relax-gp` make its way into a minor gcc point release or do we need to wait for the next major release?
>>
>> In terms of this breaking GNU users - isn't it the case that without this option, they may get silently broken code when using the shadow call stack? Breaking loudly and early seems preferable, though of course it would be best if it's easily fixable by e.g. updating to a newer released binutils.
>
> Yes, `-fsanitize=shadow-call-stack` using gp users will get silently broken code if linked with GNU ld, unless GNU ld is specified, or `-Wl,--no-relax` or `-Wl,--no-relax-gp` is specified.
> This is an instance of the guideline proposed in https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/371/commits/bb0df41a4f2626fa039173c2a975039905dce99c
>
>> For such platforms, care must be taken to ensure all code (compiler generated or otherwise) avoids using gp in a way incompatible with the platform specific purpose, and that global pointer relaxation is disabled in the toolchain.
>
> Personally I think most `-fsanitize=shadow-call-stack`  users do not use GNU ld, so this incompatibility is actually minor.
>
> `-fsanitize=shadow-call-stack` is already a quite specific configuration. For GNU ld users, I think placing the burden more on user education is fine (sorry, just that we don't have better options).

I just wanted to make sure I'm following your suggestion here. Have you come round to the idea of adding `--no-relax-gp` when shadow call stack is enabled and letting it error for users of old GNU tools on the basis that there aren't better options?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148034