Find a way to get rid of `src\tools\lld-wrapper`

[petrochenkov]

#89288 added a new wrapper tool the only purpose of which is to call LLD with the right flavor when rust-lld shipped with Rust distribution is used.

I strongly suspect that it is not necessary and the whole setup can be simplified.

The LLD executable itself is already a wrapper that does dispatch on its name and passed -flavor, we should be able to make it do what is necessary for us.
In the worst case we can patch src\llvm-project\lld\tools\lld\lld.cpp, since rust-lld is built and shipped by us using our fork of LLVM, that would still be better than a separate wrapper tool.

[petrochenkov]

Also, an advice from lld.cpp that is relevant to the way we are shipping and calling LLD:

// lld can be invoked as "lld" along with "-flavor" option. This is for
// backward compatibility and not recommended.

[petrochenkov]

I'd be interested in addressing this myself, but I cannot properly test this on Apple targets with ld64, which was one of the primary motivations for introducing the wrapper.

[bjorn3]

The LLD executable itself is already a wrapper that does dispatch on its name

That would require copying lld for every variant. As stated in the description of #89288:

Symbolic links could not be used as they are not supported by rustup and on Windows.

[petrochenkov]

I don't see why the copy named ld64 is necessary.
Pre-#88250 logic worked mostly fine, clang correctly found the ld file shipped by us, we just could add -Wl,-flavor=ld64 for it to work correctly?

UPD: The -flavor could even be passed unconditionally, like it's done with "naked" LLD (fn command in compiler\rustc_codegen_ssa\src\back\command.rs).

[petrochenkov]

Symbolic links could not be used as they are not supported by rustup and on Windows.

I'm not sure whether it's necessary to keep both rust-lld and gcc-ld/ld copies of LLD, may be it is at least for backward compatibility, and at least for some time.
In that case the wrapper can be used just as a "symlink emulation", but in that case it doesn't need to do any dispatching.

[petrochenkov]

cc @hkratz

[bjorn3]

Each variant only works for some platforms. If we only keep ld, we can't link for example for wasm or macOS. While if we keep ld64, we can link for any non-apple OS.

[petrochenkov]

Sorry, I don't understand.
A single LLD executable can (cross-)link to any platform, regardless of how its file named, if rustc passes correct -flavor (which can change depending on rustc ... --target ...).

[hkratz]

-flavor <flavor> only works if passed as the first two arguments to lld. We don't call lld directly from rustc and as far as I know there is no way to make gcc/clang insert custom arguments to the lld call at the beginning.

[petrochenkov]

Ah, I see, that's really unfortunate.
It means we'll need "symlinks" like ld64 for all LLD flavors, and that wasm-ld and lld-link are not actually yet supported by -Zgcc-ld=lld.
(lld-link doesn't make sense in combination with gcc though, mingw uses slightly hackier flavor detection based on -m options.)

[petrochenkov]

This

In the worst case we can patch src\llvm-project\lld\tools\lld\lld.cpp, since rust-lld is built and shipped by us using our fork of LLVM

is still an option though.
We can make -flavor position-independent (under the same or other name).

We can also try upstream the change, reliably passing the flavor through a C compiler is a good motivation, IMO.

[hkratz]

We can also try upstream the change, reliably passing the flavor through a C compiler is a good motivation, IMO.

There was patch that was abandoned in 2020 which is why I did not pursue that: https://reviews.llvm.org/D80184