add support for the l4-bender linker on the x86_64-unknown-l4re-uclibc tier 3 target

[atopia]

This PR contains the work by @humenda to update support for the x86_64-unknown-l4re-uclibc tier 3 target (published at humenda/rust), rebased and adapted to current rust in follow up commits by myself. The publishing of the rebased changes is authorized and preferred by the original author. As the goal was to distort the original work as little as possible, individual commits introduce changes that are incompatible to the newer code base that the changes were rebased on. These incompatibilities have been remedied in follow up commits, so that the PR as a whole should result in a clean update of the target.
If you prefer another strategy to mainline these changes while preserving attribution, please let me know.

[rust-highfive]

Some changes occured to rustc_codegen_cranelift

cc @bjorn3

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matthewjasper (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[petrochenkov]

The interface looks like more or less like an ld linker, I'd suggest to avoid adding a new linker flavor for a start and reuse GccLinker (especially given that the set of linker flavors accepted by -C linker-flavor is a stable public interface).

[humenda]

The interface looks like more or less like an `ld` linker, I'd suggest to avoid adding a new linker flavor for a start and reuse `GccLinker` (especially given that the set of linker flavors accepted by `-C linker-flavor` is a stable public interface).

It is impossible to pass in arguments with spaces to the linker due to the way how this is implemented for linkers in Rustc. I talked to Alex Crichton @alexcrichton (hopefully the correct nick) a long time ago and the suggested way has been to add a new variant. L4-bender is indeed internally using ld but it `bends` the arguments and adds quite some things and custom options. If I recall correctly, even the order of the arguments matters, something that cannot be influenced from outside. One notable one is the `--` that separates l4-bender arguments from ld arguments that are passed through. How should this be done? If a new linker flavour is really not an option, I would ask the compiler team to resume the discussion on how to quote spaces in linker flags.

[pnkfelix]

It is impossible to pass in arguments with spaces to the linker due to the way how this is implemented for linkers in Rustc. I talked to Alex Crichton @alexcrichton (hopefully the correct nick) a long time ago and the suggested way has been to add a new variant. L4-bender is indeed internally using ld but it bends the arguments and adds quite some things and custom options. If I recall correctly, even the order of the arguments matters, something that cannot be influenced from outside. One notable one is the -- that separates l4-bender arguments from ld arguments that are passed through.

I think the points made here seem to give reasonable support for adding a new linker flavor for this case.

[humenda]

I think the points made here seem to give reasonable support for adding a new linker flavor for this case.

Could we get some more support, e.g. by a rustc CI, to detect breakage earlier? Or is this something that should be done on the L4Re side due to the tier 3 support level?

[pnkfelix]

I think the points made here seem to give reasonable support for adding a new linker flavor for this case.

Could we get some more support, e.g. by a rustc CI, to detect breakage earlier? Or is this something that should be done on the L4Re side due to the tier 3 support level?

I think the latter. My understanding of the tier 3 support level is that it is not meant to impose new burdens on the existing infrastructure.

[pnkfelix]

We discussed this in today's T-compiler weekly triage meeting.

Some further review of the target tier policy led us to conclude that an MCP is not strictly required here.

I'm going to double-check the points that @petrochenkov made about the linker, but I'm currently inclined to trust @humenda 's judgement here.

Question for @humenda and @atopia : should either or both of you be recorded as maintainers for the x86_64-unknown-l4re-uclibc target? Is there anyone else who should also be on such a list of maintainers for the target?

[petrochenkov]

I'll look in more details, this all still look pretty suspicious to me.
I'm not even sure the cmd quoting and env reading stuff belongs to rustc?
There's approximately zero documentation about l4-bender on the net (if you have some info about what it does, please share), so it seems niche enough to generally adapt to rustc and not otherwise.

[petrochenkov]

Here's the version of this PR, but without introducing a new linker flavor - petrochenkov@d3b02f3
It highlights the differences from a regular gcc-style linker, I left questions about them in code.
Most of them are related to the comma vs whitespace story which is still not clear to me.
If l4-bender simply passes the arguments after -- to the underlying linker, then why does e.g. -z relro needs to be changed to -z,relro?

Also, if there are some issues with passing arguments with whitespaces, then it's better to make a separate issue (with examples from practice, showing how they behave now, and how they should behave instead) and solve it once and for all, instead of introducing more hacks for specific targets.

r? @petrochenkov

[petrochenkov]

(I'd also suggest submitting the library changes separately, in that case they will get a more appropriate reviewer familiar with library conventions and will likely land faster.)

[petrochenkov]

r=me after squashing commits.

[atopia]

@rustbot ready

[petrochenkov]

@bors r+

[bors]

📌 Commit 29d6235 has been approved by petrochenkov