Switch the linker to LLD

[pietroalbini]

Right now, all targets require the use of GCC 7.5.x as the linker, which is suboptimal for everyone not using Ubuntu 18.04 LTS. This was done because we need to test the exact linker version customers will use for qualification, and we had to pick one.

The solution we should move towards is using the LLD bundled with Ferrocene as the linker. This means updating the target specs, updating the self-testing tool to check for the right linker, and updating the target documentation.

For bare metal targets, this is as simple as changing the linker, as LLD can work with them by default (and that's actually upstream's behavior, we had to override it). Then the self-test tool can be updated to verify the presence of LLD (the code should already be there, just an enum change should be needed).

For Linux targets though we cannot invoke LLD directly, as LLD does not know where the system libraries are located. Thus, we need to use the system GCC or clang as the default linker, passing -fuse-ld=lld to it. That flag seems to work from GCC 9 onwards. This requires wider changes:

• Change the target spec to always use LLD.
• Change the self-testing tool to check for the presence of LLD, and the system linker (either gcc or clang).
• Add a new check in the self-test tool, that when compiling something, GCC or clang end up invoking LLD with the correct flags. This can be implemented by creating a fake LLD binary that checks the flags are correct: GCC/clang can then be invoked with some flags pointing to the fake LLD, which will error out if the flags are not passed through and the system flags are not present.
• In the safety manual, add a requirement for how GCC/clang should behave, and mention the self-test tool performs that check automatically.

[jonathanpallant]

Only GCC 9 and higher support -fuse-ld=ld.lld. However all this argument does is make GCC call ld.lld in your $PATH instead of ld - it makes no difference to the arguments.

So we could just rename ld.lld to ld and ensure it appears in the $PATH before the real GNU ld.

I also note that GCC and clang have a -B<prefix> argument which controls where it looks for tools it shells out to. That might be easier than trying to rig the $PATH so that our special ld appears first. Needs some testing though.

Note that you can test whether a binary was linked with ld or ld.lld, because ld produces a 14 byte Build ID and ld.lld produces an 8 byte Build ID.

Also note that ld.lld is a wrapper that calls ../rust-lld (i.e. one directory level above where ld.lld is), passing on all arguments but also adding -flavour=gnu so that rust-lld knows it should pretend to be a GNU linker (as opposed to a Windows linker, or a macOS linker, or a WASM linker).

[jonathanpallant]

Completed in #100, however we still need to update the documentation (#106) and the self-test program (#107)

[pietroalbini]

Let's track them separately, and close this issue.

[jonathanpallant]

Also, I want to clarify here some changes to our thinking. Rather than try and produce a binary called ld (which runs the risk of clashing with the system provided ld), we instead decided to check if the system supplied C compiler supports -fuse-ld=lld and if not, check to see if a suitable clang was installed. Clang is available on Ubuntu 18.04, and also knows where the system libraries live, so works as a system C compiler for our purposes.

You can also verify which linker produced any given ELF file by running:

$ readelf --string-dump .comment /path/to/elf
String dump of section '.comment':
  [     1]  rustc version 1.75.0-dev
  [    1a]  Linker: LLD 17.0.4