Add support for aarch64-unknown-linux-pauthtest target

[jchlanda]

Description

This PR adds support for aarch64-unknown-linux-pauthtest, a target that
enables Pointer Authentication Code (PAC) support in Rust on AArch64 ELF based
Linux systems using a pauthtest ABI (provided by LLVM) and pauthtest-enabled
sysroot with custom musl, serving as a reference libc implementation.

Please consult a rust-lang PR for the details on the target: rust-lang/rust#155722

Sources

This target reuses the existing musl implementation paths in libc and does not
introduce new platform-specific APIs. aarch64-unknown-linux-pauthtest should
be treated as musl-compatible.

Checklist

• Relevant tests in libc-test/semver have been updated - N/A (no semver-affecting API changes)
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);

@rustbot label +stable-nominated

[tgross35]

Based on the todo it seems like you may already be aware, but targets need to be added to rustc first as no-std. After that happens you can bring up libc, then std.

How much does the fork deviate from musl? If it’s identical but built differently, it may be worth considering setting ‘target_env=“musl”buttarget_abi=“pauthtest”` in rustc so things mostly “just work”.

[jchlanda]

Based on the todo it seems like you may already be aware, but targets need to be added to rustc first as no-std. After that happens you can bring up libc, then std.

I knew about the need for patches to libc and cc. Did not realise about the no-std first. Do you mean that the target should first have TargetMetadata.std set to false?

How much does the fork deviate from musl? If it’s identical but built differently, it may be worth considering setting ‘target_env=“musl”buttarget_abi=“pauthtest”` in rustc so things mostly “just work”.

The API surface should be identical. However they are most definitely not interchangeable.
This will be more clear once the rust-lang PR lands, but in there I've used aarch64-unknown-linux-pauthtest, and (somewhat incorrectly) gated the code on the environment part of the triple. We have a follow up task to resolve the target to a set of features, just like it's done in clang where it solves platform/environment specifics on the driver level and later on everything is based on language flags that are there regardless of the platform. And finally are resolved to a concrete signing schema.

Another deviation is that for the new target statically linked libc is not an option, so perhaps it would be good to keep the distinction clear also at the cfg checks?

[tgross35]

Rust PR for reference https://github.com/rust-lang/rust/pulls/jchlanda

[tgross35]

Based on the todo it seems like you may already be aware, but targets need to be added to rustc first as no-std. After that happens you can bring up libc, then std.

I new about the need for patches to libc and cc. Did not realise about the no-std first. Do you mean that the target should first have TargetMetadata.std set to false?

Yes, but I think that flag only controls -Zbuild-std. Beyond that, the initial r-l/r PR shouldn't touch library/std - after rustc is capable of building something for the target, it's a lot easier to bring std up incrementally. Also the initial merge of compiler support serves as an indicator to the ecosystem that the target is official, so dependencies of std know they can start accepting support patches (e.g. this crate).

How much does the fork deviate from musl? If it’s identical but built differently, it may be worth considering setting ‘target_env=“musl”buttarget_abi=“pauthtest”` in rustc so things mostly “just work”.

The API surface should be identical. However they are most definitely not interchangeable. This will be more clear once the rust-lang PR lands, but in there I've used aarch64-unknown-linux-pauthtest, and (somewhat incorrectly) gated the code on the environment part of the triple. We have a follow up task to resolve the target to a set of features, just like it's done in clang where it solves platform/environment specifics on the driver level and later on everything is based on language flags that are there regardless of the platform. And finally are resolved to a concrete signing schema.

I don't know the exact details about pauthtest but I still think what I described sounds like a reasonable enough fit. If it looks like musl for ~95% of the API then it's going to be easiest to call it target_env = "musl" since target_env mostly serves as the library config. In the more rare cases that you need to know the difference, checking target_abi = "pauthtest" will work. "Same env, different ABI" also sounds like the right intuition here from my (limited) understanding.

But that's just my thoughts, the others may feel differently. Probably worth a Zulip discussion at some point.

Another deviation is that for the new target statically linked libc is not an option, so perhaps it would be good to keep the distinction clear also at the cfg checks?

You'd still be able to cfg(target_abi = "pauthtest") where needed. And targets that support both can usually toggle +crt-static/-crt-static so code that needs to know about linkage has to be able to support both to some extent.

On that note, are there other libcs that could work for pauthtest eventually aside from the musl fork?

[jchlanda]

Moving to target_env = "musl" target_abi = "pauthtest" greatly simplified this PR.

Although the parent change (introduction of aarch64-unknown-linux-pauthtest) has not landed yet, it seems this should not prevent this PR from being marked as ready for review.

[jchlanda]

@davidtwco, @folkertdev, @tgross35, @madsmtm FWI this is a follow up to rust-lang/rust#155722

[tgross35]

@rustbot blocked, until rust-lang/rust#155722 goes through

[jchlanda]

Hi @tgross35

The PR introducing the pauthtest target has been merged into main. I'd be very grateful if we could move this one forward as well. Please let me know if you'd like anything else done for this PR.

Thank you!

[tgross35]

You'll need to update

libc/build.rs

Line 41 in 03ff348

const CHECK_CFG_EXTRA: &[(&str, &[&str])] = &[

but otherwise LGTM, this is much cleaner.

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[tgross35]

Add // FIXME(msrv) and note this is 1.78:

View changes since the review

[jchlanda]

Done.

[tgross35]

Thanks! Please squash then LGTM

View changes since this review

[jchlanda]

Please not, the failure: https://github.com/rust-lang/libc/actions/runs/28580626120/job/84739740809?pr=5065#step:9:2195
doesn't seem to be related to this patch, c_void_returns lint triggers in src/unix/aix/mod.rs.

[folkertdev]

Latest nightly added a lint warning on -> c_void, so yeah this is not your fault, just needs a fix here probably.

[jchlanda]

Latest nightly added a lint warning on -> c_void, so yeah this is not your fault, just needs a fix here probably.

I've addressed it in here: #5240
Will wait for fix PR to go in and rebase this one afterwards.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.