Add library support for aarch64-unknown-linux-pauthtest#1
Open
jchlanda wants to merge 443 commits into
Open
Conversation
jchlanda
force-pushed
the
jakub/pac_lib
branch
2 times, most recently
from
6896ebd to
2af080b
Compare
jchlanda
force-pushed
the
jakub/pac
branch
3 times, most recently
from
778d3ab to
2f8bcb1
Compare
jchlanda
force-pushed
the
jakub/pac_lib
branch
2 times, most recently
from
0077f1d to
cf8cea4
Compare
jchlanda
force-pushed
the
jakub/pac_lib
branch
2 times, most recently
from
6f7739c to
50a986f
Compare
Previous limit of 40,000 is now broken by 2,281 bytes.
…Simulacrum Move `std::io::Error` into `core` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 Related: rust-lang#155574 Related: rust-lang#152918 ## Description Moves `std::io::Error` into `core`, deferring `Box`-adjacent methods to incoherent implementations in `alloc`, and `RawOsError` methods to `std`. This requires some substantial changes to the internals of `Error`, but none of them are breaking changes or externally visible. Notably, I've replaced usage of `Box` with a wrapper around a pointer and an appropriate drop function. This requires the addition of quite a few lines of unsafe, but is required to work around `Box` only being accessible from `alloc`. Additionally, an atomic pointer to a VTable is used for working with `RawOsError` in `core`, since we cannot know the required implementations without `std`. As mention in [this comment](rust-lang#155625 (comment)), there may be concern around having a static `AtomicPtr` in `core` for certain users. I've added a configuration option `no_io_statics` which (similar to `no_sync`/etc. in `alloc`) can be used to prevent their inclusion in `core`. When active, the fallback default implementation will always be used. --- ## Notes * This PR adopts the VTable technique from rust-lang#152918 * This PR builds on my previous PR rust-lang#155574 * No AI tooling of any kind was used during the creation of this PR.
Also link back to a relevant issue to track possible changes in functionality.
…li-obk Remove redundant dyn-compatibility check. This check is already handled in [`rustc_trait_selection::traits::fulfill::FulfillProcessor::process_obligation`](https://github.com/rust-lang/rust/blob/16761606d606b6ec4d0c88fc9251670742ad9fd2/compiler/rustc_trait_selection/src/traits/fulfill.rs#L524). r? types
…r=jdonszelmann lint ImproperCTypes: refactor linting architecture (part 3) This is the third PR in an effort to split rust-lang#134697 (refactor plus overhaul of the ImproperCTypes family of lints) into individually-mergeable parts. Contains: - the changes of the first two PRs - other user-invisible changes, - the prevention of stack overflows while checking irregular recursive types. Fixes: rust-lang#130310 Superset of: rust-lang#146271 and its superset rust-lang#146273
…ent into `PathSegment`
…w_mut` on `RefCell<NameResolution>`. Use a TLS for this set ahead of parallel import resolution.
In LLVM, FeatureKV/SubtargetKV pointers are now private: llvm/llvm-project#206237 This change fixes compiler errors when building rustc with ToT LLVM by using the key() and desc() accessors.
…=petrochenkov resolve: Explicit Set for detecting resolution cycles Instead of using the `borrow_mut` counter of a `RefCell` for a `NameResolution` for detecting cyclic imports during import resolution, we use an explicit recursion stack that keeps track of the current used `NameResolution`s. Because of the upcoming parallelisation of the import resolution algorithm, the current way cannot used in a parallel context. r? @petrochenkov
And not just the self type. rustc does not make use of this, but rust-analyzer needs it to support impls in the same block as args, see https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/non.20local.20impls.20for.20generic.20args/with/593629693. I'm not entirely sure this covers all cases (e.g. an unnormalized alias), and wants feedback from a types team member.
Introduce aarch64-unknown-linux-pauthtest target This target enables Pointer Authentication Code (PAC) support in Rust on AArch64 ELF-based Linux systems. It uses the `aarch64-unknown-linux-pauthtest` LLVM target and a pointer-authentication-enabled sysroot with a custom musl as a reference libc implementation. Dynamic linking is required, with a dynamic linker acting as the ELF interpreter that can resolve pauth relocations and enforce pointer authentication constraints. ### Supported features include: * authentication of signed function pointers for extern "C" calls (corresponds to LLVM's `-fptrauth-calls`) * signing of return addresses before spilling to the stack and authentication after restoring for non-leaf functions (corresponds to `-fptrauth-returns`) * trapping on authentication failure when the FPAC feature is not present (corresponds to `-fptrauth-auth-traps`) * signing of init/fini array entries using the LLVM-defined pointer authentication scheme (corresponds to `-fptrauth-init-fini` and `-fptrauth-init-fini-address-discrimination`) * non-ABI-affecting indirect control-flow hardening features as implemented in LLVM (corresponds to `-faarch64-jump-table-hardening` and `-fptrauth-indirect-gotos`) * signed ELF GOT entries (gated behind `-Z ptrauth-elf-got`, off by default) Existing compiler support, such as enabling branch authentication instructions (i.e.: `-Z branch-protection`) provide limited functionality, mainly signing return addresses (`pac-ret`). The new target goes further by enabling ABI-level pointer authentication support. This target does not define a new ABI; it builds on the existing C/C++ language ABI with pointer authentication support added. However, different authentication features, encoded in the signing schema, are not ABI-compatible with one another. ### Useful links: * Earlier PR: rust-lang#154759 * Part of: rust-lang#148640 * Project goal: https://rust-lang.github.io/rust-project-goals/2026/aarch64_pointer_authentication_pauthtest.html * Clang pointer authentication documentation: https://clang.llvm.org/docs/PointerAuthentication.html * LLVM pointer authentication documentation: https://llvm.org/docs/PointerAuth.html * PAuth ABI Extension to ELF for the AArch64 architecture: https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst ### Tier 3 check list > - A tier 3 target must have a designated developer or developers (the "target > maintainers") on record to be CCed when issues arise regarding the target. > (The mechanism to track and CC such developers may evolve over time.) I pledge to do my best maintaining it. > - Targets must use naming consistent with any existing targets; for instance, a > target for the same CPU or OS as an existing Rust target should use the same > name for that CPU or OS. Targets should normally use the same names and > naming conventions as used elsewhere in the broader ecosystem beyond Rust > (such as in other toolchains), unless they have a very good reason to > diverge. Changing the name of a target can be highly disruptive, especially > once the target reaches a higher tier, so getting the name right is important > even for a tier 3 target. The name chosen for the target is `aarch64-unknown-linux-pauthtest` which mirrors the [LLVM target naming](https://github.com/llvm/llvm-project/blob/main/llvm/unittests/TargetParser/TripleTest.cpp#L1407). > - Target names should not introduce undue confusion or ambiguity unless > absolutely necessary to maintain ecosystem compatibility. For example, if > the name of the target makes people extremely likely to form incorrect > beliefs about what it targets, the name should be changed or augmented to > disambiguate it. There should be no confusion, the name follows naming convention and is descriptive. > - If possible, use only letters, numbers, dashes and underscores for the name. > Periods (`.`) are known to cause issues in Cargo. Letters, numbers and dashes only. > - Tier 3 targets may have unusual requirements to build or use, but must not > create legal issues or impose onerous legal terms for the Rust project or for > Rust developers or users. The target requires system `clang` and `lld` available as well as custom libc ([musl](https://github.com/access-softek/musl) based) and sysroot, provided [through the build scripts](https://github.com/access-softek/pauth-toolchain-build-scripts/tree/master). > - The target must not introduce license incompatibilities. There are no license implications. > - Anything added to the Rust repository must be under the standard Rust > license (`MIT OR Apache-2.0`). Understood. > - The target must not cause the Rust tools or libraries built for any other > host (even when supporting cross-compilation to the target) to depend > on any new dependency less permissive than the Rust licensing policy. This > applies whether the dependency is a Rust crate that would require adding > new license exceptions (as specified by the `tidy` tool in the > rust-lang/rust repository), or whether the dependency is a native library > or binary. In other words, the introduction of the target must not cause a > user installing or running a version of Rust or the Rust tools to be > subject to any new license requirements. There are no new dependencies or requirements. > - Compiling, linking, and emitting functional binaries, libraries, or other > code for the target (whether hosted on the target itself or cross-compiling > from another target) must not depend on proprietary (non-FOSS) libraries. > Host tools built for the target itself may depend on the ordinary runtime > libraries supplied by the platform and commonly used by other applications > built for the target, but those libraries must not be required for code > generation for the target; cross-compilation to the target must not require > such libraries at all. For instance, `rustc` built for the target may > depend on a common proprietary C runtime library or console output library, > but must not depend on a proprietary code generation library or code > optimization library. Rust's license permits such combinations, but the > Rust project has no interest in maintaining such combinations within the > scope of Rust itself, even at tier 3. The target only relies on open source tools. > - "onerous" here is an intentionally subjective term. At a minimum, "onerous" > legal/licensing terms include but are *not* limited to: non-disclosure > requirements, non-compete requirements, contributor license agreements > (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, > requirements conditional on the employer or employment of any particular > Rust developers, revocable terms, any requirements that create liability > for the Rust project or its developers or users, or any requirements that > adversely affect the livelihood or prospects of the Rust project or its > developers or users. No such terms present. > - Neither this policy nor any decisions made regarding targets shall create any > binding agreement or estoppel by any party. If any member of an approving > Rust team serves as one of the maintainers of a target, or has any legal or > employment requirement (explicit or implicit) that might affect their > decisions regarding a target, they must recuse themselves from any approval > decisions regarding the target's tier status, though they may otherwise > participate in discussions. Understood. > - This requirement does not prevent part or all of this policy from being > cited in an explicit contract or work agreement (e.g. to implement or > maintain support for a target). This requirement exists to ensure that a > developer or team responsible for reviewing and approving a target does not > face any legal threats or obligations that would prevent them from freely > exercising their judgment in such approval, even if such judgment involves > subjective matters or goes beyond the letter of these requirements. Understood. > - Tier 3 targets should attempt to implement as much of the standard libraries > as possible and appropriate (`core` for most targets, `alloc` for targets > that can support dynamic memory allocation, `std` for targets with an > operating system or equivalent layer of system-provided functionality), but > may leave some code unimplemented (either unavailable or stubbed out as > appropriate), whether because the target makes it impossible to implement or > challenging to implement. The authors of pull requests are not obligated to > avoid calling any portions of the standard library on the basis of a tier 3 > target not implementing those portions. `aarch64-unknown-linux-pauthtest target` has std library support, moreover all `library` tests pass for the target. > - The target must provide documentation for the Rust community explaining how > to build for the target, using cross-compilation if possible. If the target > supports running binaries, or running tests (even if they do not pass), the > documentation must explain how to run such binaries or tests for the target, > using emulation if possible or dedicated hardware if necessary. Platform support document covers building instructions. > - Tier 3 targets must not impose burden on the authors of pull requests, or > other developers in the community, to maintain the target. In particular, > do not post comments (automated or manual) on a PR that derail or suggest a > block on the PR based on a tier 3 target. Do not send automated messages or > notifications (via any medium, including via `@`) to a PR author or others > involved with a PR regarding a tier 3 target, unless they have opted into > such messages. Understood. > - Backlinks such as those generated by the issue/PR tracker when linking to > an issue or PR are not considered a violation of this policy, within > reason. However, such messages (even on a separate repository) must not > generate notifications to anyone involved with a PR who has not requested > such notifications. Understood. > - Patches adding or updating tier 3 targets must not break any existing tier 2 > or tier 1 target, and must not knowingly break another tier 3 target without > approval of either the compiler team or the maintainers of the other tier 3 > target. Understood. > - In particular, this may come up when working on closely related targets, > such as variations of the same architecture with different features. Avoid > introducing unconditional uses of features that another variation of the > target may not have; use conditional compilation or runtime detection, as > appropriate, to let each target run code supported by that target. Understood. > - Tier 3 targets must be able to produce assembly using at least one of > rustc's supported backends from any host target. (Having support in a fork > of the backend is not sufficient, it must be upstream.) It is expected that the target should be able to compile binaries on any systems that are capable of compiling `aarch64` code.
…uiltins-object-arch, r=tgross35 tests: check wasm compiler_builtins object architecture See rust-lang#132802 This adds a run-make test for the wasm sysroot regression fixed in rust-lang#137457 The test checks that the `.o` members in the prebuilt `libcompiler_builtins` rlib for `wasm32-wasip1` are wasm objects rather than host ELF objects. Before that fix, bootstrap could use the host C compiler for compiler-rt fallbacks on wasm targets and end up embedding host objects into the wasm sysroot. I used `wasm32-wasip1` because that's the wasm target covered by the existing `tests/run-make` CI setup, and the test asserts that it actually saw `.o` members in the archive. Closes: rust-lang#132802 r? @tgross35
…, r=lcnr Pass the whole `GenericArgs` to `Interner::for_each_relevant_impl()` Pass the whole `GenericArgs` to `Interner::for_each_relevant_impl()` And not just the self type. rustc does not make use of this, but rust-analyzer needs it to support impls in the same block as args, see https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/non.20local.20impls.20for.20generic.20args/with/593629693. I'm not entirely sure this covers all cases (e.g. an unnormalized alias), and want feedback from a types team member. r? types
…tem, r=BoxyUwU Support `DefKind::InlineConst` in `ConstKind::Unevaluated` fixes rust-lang/project-const-generics#101 required for rust-lang/project-const-generics#108 consider: `Struct<{ (some, stuff, const { hi }) }>`. The following is very pseudocode-y, the important parts are whether it says AnonConst or InlineConst, not the Tuple stuff - On stable, we represent this with: `AnonConst(Tuple(some, stuff, InlineConst(hi)))` - Under mGCA, with "direct" arguments, before this PR, it was `Tuple(some, stuff, AnonConst(hi))`. The inner InlineConst got intercepted in the def_collector with hacks (`ConstArgContext`) and converted into an AnonConst, even though it has inline const syntax. It would be nice to keep it as an InlineConst under mGCA, i.e. `Tuple(some, stuff, InlineConst(hi))`, and have the type system support passing around InlineConsts in `ConstKind::Unevaluated` (soon to be renamed `ConstKind::Alias`). This would allow the def collector to not need to know if we are in a "direct" or "regular/anon" context, which it turns out is extremely useful for implementing rust-lang/project-const-generics#108. Supporting InlineConsts in the type system are also useful for other things, for example, mentioned in rust-lang/project-const-generics#101 is arg position const generics experiments. This PR does two things: - support InlineConsts in the type system (i.e. in `ConstKind::Unevaluated`) - exercise that support, by no longer intercepting mGCA "direct" argument inline consts to be anon consts r? @BoxyUwU
…-perf, r=petrochenkov delegation: store child segment flag in `PathSegment` This should reduce [perf overhead](rust-lang#157960 (comment)) of checking whether path segment is a delegation's child segment. r? @petrochenkov
…closure_recovery, r=nnethercote trait-system: Recover deferred closure calls after errors fixes rust-lang#157951 this already reported the right errors, then typeck kept going and hit the deferred closure call path. that path assumed it could always find a fn trait impl after closure kind inference. with this repro, the earlier errors mean that lookup can fail, so it should recover instead of iceing. i think keeping this as recovery is the least surprising fix here. the compiler has already told the user what's wrong, so turning the later invariant into another hard failure doesn't buy much. also drops the weird e0746 help for this closure case. there's no written ret ty to edit, so suggestions like \impl f\ or \�ox<dyn box::new(f)>\ were just noise. added the next-solver ui test for the repro.
…ty, r=GuillaumeGomez Include default-stability info in rustdoc JSON. Add a `default_unstable` field on associated constants, associated types, and functions. The field is populated only when those items appear inside a trait, only when there's a default present, and when that default is not stable as designated by `#[rustc_default_body_unstable]`. In such a case, the field contains the name of the feature required to use the unstable default. The purpose of this info is to allow `cargo-semver-checks` to lint the standard library for accidental breakage of stable APIs. Removing a stable default is an example of such breakage, while removing an _unstable_ default is not. The field is boxed to minimize the size impact on its enclosing type, since for regular crates it will always be `None`. I also updated `jsondoclint` to assert that it's an error to have a populated `default_unstable` when there's no function body, no default const value, or no default associated type. In the process, I noticed that `jsondoclint` and `jsondocck` are both on edition 2021 — I plan to upgrade them to 2024 in separate PRs. r? @GuillaumeGomez **AI disclosure:** This PR is the product of a combination of manual work and AI tools. I secured approval in advance from the designated reviewer. I stand behind the quality of the code I'm submitting, and I vouch it's as good or better compared to if I had written every line by my own hand.
…docs, r=Mark-Simulacrum Note usage of documentation hard links in `core::io` ACP: rust-lang/libs-team#755 Tracking issue: rust-lang#154046 Split From: rust-lang#156527 ## Description Hard-links have been used to move items from `std::io` into `core` and `alloc`, but they should link back to rust-lang#74481 with a `FIXME` so they can be addressed once a better solution is available. --- ## Notes * No AI tooling of any kind was used during the creation of this PR. * Please see rust-lang#154046 (comment) for a review order and broader context for this PR.
fix `-Z min-recursion-limit` unstable chapter name This fixes the unstable documentation chapter name for `-Z min-recursion-limit` from rust-lang#153188: it currently shows up as [`min_recursive_limit`](https://doc.rust-lang.org/beta/unstable-book/compiler-flags/min-recursive-limit.html) in the URL and TOC, instead of `min_recursion_limit`. r? Kivooeo or anyone @bors rollup=always
llvm-wrapper: use accessors for private fields in LLVM 23+ In LLVM, FeatureKV/SubtargetKV pointers are now private: llvm/llvm-project#206237 This change fixes compiler errors when building rustc with ToT LLVM by using the key() and desc() accessors.
…-stacks.rs, r=mejrs Comment on needed RAM in huge-stacks.rs We were asked to make this test error with a more useful message for external CIs with resource-constrained runners.
…nathanBrouwer Rollup of 11 pull requests Successful merges: - rust-lang#155722 (Introduce aarch64-unknown-linux-pauthtest target) - rust-lang#156230 (tests: check wasm compiler_builtins object architecture) - rust-lang#156295 (Pass the whole `GenericArgs` to `Interner::for_each_relevant_impl()`) - rust-lang#158375 (Support `DefKind::InlineConst` in `ConstKind::Unevaluated`) - rust-lang#158556 (delegation: store child segment flag in `PathSegment`) - rust-lang#158081 (trait-system: Recover deferred closure calls after errors) - rust-lang#158468 (Include default-stability info in rustdoc JSON.) - rust-lang#158543 (Note usage of documentation hard links in `core::io`) - rust-lang#158564 (fix `-Z min-recursion-limit` unstable chapter name) - rust-lang#158568 (llvm-wrapper: use accessors for private fields in LLVM 23+) - rust-lang#158582 (Comment on needed RAM in huge-stacks.rs)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a follow up to the introduction of
aarch64-unknown-linux-pauthtestPR.Apart from threading through
pauthtestenvironment, the main change this PR brings is signing of the landing pad entries.