Improve default target options for x86_64-unknown-linux-none

[Noratrieb]

Without a standard library, we cannot unwind, so it should be panic=abort by default.

Additionally, it does not have std because while it is Linux, it cannot use libc, which std uses today for Linux.

Thirdly, relocation-model=pie is a very funny default because it forces users to write their own dynamic loader, which is fun, but probably not the most appropriate default for this target. If someone wants to write a dynamic loader, they should, but they should explicitly ask for PIE.

fixes #134763

cc @morr0ne, as you added the target, and @Noratrieb, who reviewed that PR (:D).

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

[morr0ne]

The panic abort looks good to me. For context, it was actually more of an oversight since I already use this cargo config in most/all of my test projects:

[unstable]
build-std = ["core", "compiler_builtins", "alloc"]
build-std-features = ["compiler-builtins-mem", "panic_immediate_abort"]

[build]
rustflags = ["-Cpanic=abort"]
target = "x86_64-unknown-linux-none"

About std support - we might add it in the future, but that's still up for discussion. If we do end up getting std support for the target, changing the default panicking strategy should be fine. I don't think rust targets make any guarantees about that.

For the relocation model, I'm running some tests right now. To be honest, I need to check if there was a specific reason for defaulting to PIE or if I just overlooked it when writing the target. I remember having some interesting discussions about this with the maintainer of rustix and origin, which might have factored into the decision - I'll look back at those conversations.

[workingjubilee]

About std support - we might add it in the future, but that's still up for discussion. If we do end up getting std support for the target, changing the default panicking strategy should be fine. I don't think rust targets make any guarantees about that.

In general targets are not beholden to such, no.

[morr0ne]

After digging deeper, I have some reservations about switching to a static relocation model. One of the primary goals with this target is enabling developers to write both a libc and dynamic linker in rust. This means we need to support building shared objects that are themselves dynamically linked. From what I understand, supporting dynamic linking requires the target to use a pic model by default. This is actually why the ci is failing with:

"targets that support dynamic linking must use the `pic` relocation model"

It seems we need to keep the current default. While this target is somewhat unique, I suspect this requirements here exists for good technical reasons.

As an alternative solution, what if we added a note in the target documentation recommending the static relocation model for most use cases, along with an example cargo config showing how to set this up?

[workingjubilee]

I believe people can still override the default, no?

[morr0ne]

I believe people can still override the default, no?

They can ovveride the relocation model, which is what you are "supposed" to do right now. But afaik the target is what decides if dynamic relocation is supported or not.

Outdated

[Noratrieb]

That makes sense. In that case, I will leave it as PIE by default. I added that to the documentation.

[morr0ne]

LGTM

[josephcsible]

I don't think this is quite true, since C programs compiled with -static-pie work with no dynamic linker. What about something like this instead?

Suggested change

	To be able to run a PIE, you need a dynamic linker.
	PIE binaries need relocation at runtime. This is usually done by the dynamic linker or libc.

And maybe something to the effect of "Since the point of this target is to not require those things, you may not want a PIE binary."

[RalfJung]

PR description and PR diff do not seem to be in sync any more.