[lld][driver] Add `--relax-gp`/`no-relax-gp` flags for GNU compatibility

[MaskRay]

Summary

GNU LD accepts --relax-gp/--no-relax-gp to control GP relaxation.

Since gp (x3) is being defined as the platform register in the
RISC-V psABI, LLD needs to be able to handle flags that disable gp
relaxation. The use of gp as the shadow call stack register is a prime
example of when a compiler aught to set such a flag for the linker, so
that linker relaxation won't conflict with the platform's usage of the
register.

This patch only adds the flag for compatibility, since LLD does not yet
implement GP relaxation, which will not conflict with a platform's usage
of the RISC-V GP register.

[mcgrathr]

lgtm

[MaskRay]

Thank for the patch, but we can just wait for GP relaxation which should land soon.

[mcgrathr]

In D147983#4259054, @MaskRay wrote:

Thank for the patch, but we can just wait for GP relaxation which should land soon.

If it's not landing literally by tomorrow, then we should land this first to unblock other work that needs to rely on RISC-V linkers accepting these flags since GNU linkers have --relax-gp as the default state and we need target-specific driver logic to be able to override that. This seems far preferable to making such driver logic temporarily omit the option when it thinks it's running LLD.

[MaskRay]

In D147983#4259079, @mcgrathr wrote:

In D147983#4259054, @MaskRay wrote:

Thank for the patch, but we can just wait for GP relaxation which should land soon.

If it's not landing literally by tomorrow, then we should land this first to unblock other work that needs to rely on RISC-V linkers accepting these flags since GNU linkers have --relax-gp as the default state and we need target-specific driver logic to be able to override that. This seems far preferable to making such driver logic temporarily omit the option when it thinks it's running LLD.

Thank you for weighing in in shadow call stack. Apologies if I have missed any previous discussions as I had been travelling for quite a while for the past 30 days and just came back and started to check emails.

However, I don't think this is needed to unblock any dependent work.
I added --[no-]relax-gp to GNU ld recently, which isn't in a released binutils version yet.
Clang Driver passing --no-relax-gp to ld will break most GNU ld users.

This patch has some other issues that should be addressed before being in a ready state. For ignored options, we use silent-ignore.test as a convention.
For ignored options, we don't need to use TableGen names defm relax_gp.

[MaskRay]

With the above said, I acknowledge the need of --relax-gp and just made another comment on D143673 to prioritize the work.

[paulkirth]

Address comments.

[paulkirth]

Fix whitespace and simplify test.

[paulkirth]

Fix remaining whitespace, not added to last commit.

[paulkirth]

I don't see the issue with landing this change for now , and allowing D143673 to revert it when landing. I think that keeps the world in a more consistent state, right? ToT GNU LD accepts the flags, and thus ToT LLD will too.

The other think I'd point out is that I think we do need to start setting this option in the clang driver as part of adopting the new platform register for shadow call stack.
I don't expect that to affect many users, since AFAIK only Fuchsia and Android are looking into using SCS on RISC-V.

The unfortunate fact is that we're in a situation where people are using the latest GNU LD and running into trouble because the compiler doesn't communicate that well to the linker.
They can certainly work around that, but I don't see this as significantly different from setting other linker related options for other sanitizers.

Would you mind elaborating on your views here, and the rationale for why we wouldn't want to do that now?

[MaskRay]

In D147983#4259281, @paulkirth wrote:

I don't see the issue with landing this change for now , and allowing D143673 to revert it when landing. I think that keeps the world in a more consistent state, right? ToT GNU LD accepts the flags, and thus ToT LLD will too.

The other think I'd point out is that I think we do need to start setting this option in the clang driver as part of adopting the new platform register for shadow call stack.
I don't expect that to affect many users, since AFAIK only Fuchsia and Android are looking into using SCS on RISC-V.

The unfortunate fact is that we're in a situation where people are using the latest GNU LD and running into trouble because the compiler doesn't communicate that well to the linker.
They can certainly work around that, but I don't see this as significantly different from setting other linker related options for other sanitizers.

Would you mind elaborating on your views here, and the rationale for why we wouldn't want to do that now?

See https://reviews.llvm.org/D148034#4262991

[MaskRay]

--no-relax-gp has been added. This can be abandoned.

lld/test/ELF/silent-ignore.test

10

Note: double --no-relax

lld/ELF/Options.td

 def: J<"rpath-link=">;
 def: F<"secure-plt">;
 def: F<"sort-common">;
 def: F<"stats">;
 def: F<"warn-execstack">;
 def: F<"warn-once">;
 def: F<"warn-shared-textrel">;
 def: JoinedOrSeparate<["-"], "G">;
+def: F<"relax-gp">;
+def: F<"no-relax-gp">;
 
 // Hidden option used for testing MIPS multi-GOT implementation.
 defm mips_got_size:
   Eq<"mips-got-size", "Max size of a single MIPS GOT. 0x10000 by default.">,
   Flags<[HelpHidden]>;
 
 // Hidden option used to opt-in to additional output checks.
 defm check_dynamic_relocations: BB<"check-dynamic-relocations",

lld/test/ELF/silent-ignore.test

 RUN: ld.lld --version \
 RUN:   -d \
 RUN:   -g \
 RUN:   -long-plt \
 RUN:   --no-add-needed \
 RUN:   -no-copy-dt-needed-entries \
 RUN:   -no-ctors-in-init-array \
 RUN:   -no-keep-memory \
 RUN:   --no-relax \
+RUN:   --no-relax \
+RUN:   --no-relax-gp \
 RUN:   -no-warn-mismatch \
 RUN:   -rpath-link . \
 RUN:   -secure-plt \
 RUN:   -sort-common \
 RUN:   -stats \
 RUN:   -warn-execstack \
 RUN:   -warn-once \
 RUN:   -warn-shared-textrel \