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.

Using PIE by default may be surprising to users, as shown in #134763, so I've documented it explicitly. I'm not sure if we want to count that as fixing the issue or not.

cc @morr0ne, as you added the target (and are the maintainer), 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

[RalfJung]

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

[jieyouxu]

Thanks, you can r=me after PR CI is green, since the changes looks good to the target maintainer as well.

[jieyouxu]

FWIW I think we can consider #134763 "fixed" in that we now explicitly document that PIE is used by default, and the user can override this default with -Crelocation-model=static if they want a position-dependent executable.

Also tagging this with relnotes because it modifies a Tier 3 target default (Tier 3, but still good for FYI).
@/rustbot label +relnotes

EDIT: nevermind, I don't think the changes here specifically needs relnotes

[Noratrieb]

that looks green to me
@bors r=jieyouxu

[bors]

📌 Commit b235cc9 has been approved by jieyouxu

It is now in the queue for this repository.

[bors]

⌛ Testing commit b235cc9 with merge 14ee63a...

[bors]

☀️ Test successful - checks-actions
Approved by: jieyouxu
Pushing 14ee63a to master...

[rust-timer]

Finished benchmarking commit (14ee63a): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (secondary 0.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.9%	[-0.9%, -0.9%]	1
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.0%	[2.0%, 2.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 761.047s -> 761.533s (0.06%)
Artifact size: 325.44 MiB -> 325.42 MiB (-0.01%)