abort in core rust-lang/rust#154604
Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.
r? @scottmcm
rustbot has assigned @scottmcm.
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
Why was this reviewer chosen?
The reviewer was selected based on:
- Owners of files modified in this PR:
@scottmcm,libs @scottmcm,libsexpanded to 8 candidates- Random selection from
Mark-Simulacrum,scottmcm
tests/ui/extern-flag and tests/ui/no_std caught that __rust_abort still wasn't being defined. I think this must be because std is available (and thus lang = "abort_impl" is defined, but #![no_std] means that we aren't linking std. I'm now looking for how to directly gate the shim on if std is getting linked, to avoid adding a new requirement to no_std binaries.
Cc @bjorn3 who knows a lot about the alloc shims.
library/core/src/process.rs · outdated
| 47 | pub mod __default_core_abort { |
|
| 48 | #[rustc_std_internal_symbol] |
|
| 49 | pub fn __rdl_abort() -> ! { |
|
| 50 | super::abort_immediate() |
|
| 51 | } |
|
| 52 | } |
This looks like it wants to be an externally defined item...
EIIs still don’t work on Windows.
I would stongly prefer waiting until EIIs are ready before we add any more EII like interfaces.
library/core/src/process.rs · outdated
| 38 | } |
|
| 39 | |
|
| 40 | __rust_abort() |
|
| 41 | } |
Would you mind adding a Miri test for this, to ensure the symbol dispatch also works there? Ideally with two revisions to cover both the no_std and with_std case. src/tools/miri/tests/fail/shims is probably the right folder for that.
View on GitHub
The job aarch64-gnu-llvm-21-2 failed! Check out the build log: (web) (plain enhanced) (plain)
Click to see the possible cause of the failure (guessed by this bot)
Executing "/scripts/stage_2_test_set2.sh"
+ /scripts/stage_2_test_set2.sh
PR_CI_JOB set; skipping tidy
+ '[' 1 == 1 ']'
+ echo 'PR_CI_JOB set; skipping tidy'
+ SKIP_TIDY='--skip tidy'
+ ../x.py --stage 2 test --skip tidy --skip tests --skip coverage-map --skip coverage-run --skip library --skip tidyselftest
##[group]Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.04s
##[endgroup]
downloading https://static.rust-lang.org/dist/2026-03-05/rustfmt-nightly-aarch64-unknown-linux-gnu.tar.xz
---
##[endgroup]
[TIMING:end] tool::ToolBuild { build_compiler: Compiler { stage: 0, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu, tool: "linkchecker", path: "src/tools/linkchecker", mode: ToolBootstrap, source_type: InTree, extra_features: [], allow_features: "", cargo_args: [], artifact_kind: Binary } -- 0.143
[TIMING:end] tool::Linkchecker { compiler: Compiler { stage: 0, host: aarch64-unknown-linux-gnu, forced_compiler: false }, target: aarch64-unknown-linux-gnu } -- 0.000
##[group]Testing stage1 Linkcheck (aarch64-unknown-linux-gnu)
std/process/fn.abort_immediate.html:7: broken link - `std/fn.abort.html`
core/process/fn.abort_immediate.html:7: broken link - `core/fn.abort.html`
NOTE: if you are adding or renaming a markdown file in a mdBook, don't forget to register the page in SUMMARY.md
checked links in: 23.3s
number of HTML files scanned: 49020
number of HTML redirects found: 15651
number of links checked: 2678076
number of links ignored due to external: 132634
---
2: <std::backtrace::Backtrace>::create
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/std/src/backtrace.rs:331:13
3: <bootstrap::utils::exec::DeferredCommand>::finish_process
at /checkout/src/bootstrap/src/utils/exec.rs:939:17
4: <bootstrap::utils::exec::DeferredCommand>::wait_for_output::<&bootstrap::utils::exec::ExecutionContext>
at /checkout/src/bootstrap/src/utils/exec.rs:831:21
5: <bootstrap::utils::exec::ExecutionContext>::run
at /checkout/src/bootstrap/src/utils/exec.rs:741:45
6: <bootstrap::utils::exec::BootstrapCommand>::run::<&bootstrap::core::builder::Builder>
at /checkout/src/bootstrap/src/utils/exec.rs:339:27
7: <bootstrap::core::build_steps::test::Linkcheck as bootstrap::core::builder::Step>::run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:190:77
8: <bootstrap::core::builder::Builder>::ensure::<bootstrap::core::build_steps::test::Linkcheck>
at /checkout/src/bootstrap/src/core/builder/mod.rs:1579:36
9: <bootstrap::core::build_steps::test::Linkcheck as bootstrap::core::builder::Step>::make_run
at /checkout/src/bootstrap/src/core/build_steps/test.rs:136:21
10: <bootstrap::core::builder::StepDescription>::maybe_run
at /checkout/src/bootstrap/src/core/builder/mod.rs:476:13
11: bootstrap::core::builder::cli_paths::match_paths_to_steps_and_run
at /checkout/src/bootstrap/src/core/builder/cli_paths.rs:141:22
12: <bootstrap::core::builder::Builder>::run_step_descriptions
at /checkout/src/bootstrap/src/core/builder/mod.rs:1122:9
13: <bootstrap::core::builder::Builder>::execute_cli
at /checkout/src/bootstrap/src/core/builder/mod.rs:1101:14
14: <bootstrap::Build>::build
at /checkout/src/bootstrap/src/lib.rs:799:25
15: bootstrap::main
at /checkout/src/bootstrap/src/bin/main.rs:130:11
16: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/core/src/ops/function.rs:250:5
17: std::sys::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/std/src/sys/backtrace.rs:166:18
18: std::rt::lang_start::<()>::{closure#0}
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/std/src/rt.rs:206:18
19: <&dyn core::ops::function::Fn<(), Output = i32> + core::panic::unwind_safe::RefUnwindSafe + core::marker::Sync as core::ops::function::FnOnce<()>>::call_once
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/core/src/ops/function.rs:287:21
20: std::panicking::catch_unwind::do_call::<&dyn core::ops::function::Fn<(), Output = i32> + core::panic::unwind_safe::RefUnwindSafe + core::marker::Sync, i32>
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/std/src/panicking.rs:581:40
21: std::panicking::catch_unwind::<i32, &dyn core::ops::function::Fn<(), Output = i32> + core::panic::unwind_safe::RefUnwindSafe + core::marker::Sync>
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/std/src/panicking.rs:544:19
22: std::panic::catch_unwind::<&dyn core::ops::function::Fn<(), Output = i32> + core::panic::unwind_safe::RefUnwindSafe + core::marker::Sync, i32>
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/std/src/panic.rs:359:14
23: std::rt::lang_start_internal::{closure#0}
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/std/src/rt.rs:175:24
24: std::panicking::catch_unwind::do_call::<std::rt::lang_start_internal::{closure#0}, isize>
at /rustc/ad726b5063362ec9897ef3d67452fc5606ee70fa/library/std/src/panicking.rs:581:40
---
31: __libc_start_main
32: _start
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:37:44
local time: Mon Mar 30 21:00:38 UTC 2026
network time: Mon, 30 Mar 2026 21:00:38 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"
compiler/rustc_codegen_ssa/src/base.rs · outdated
| 683 | inputs: &[], |
|
| 684 | output: AllocatorTy::Never, |
|
| 685 | }); |
|
| 686 | } |
The allocator shim is only codegened when liballoc is pulled in.
Imagine the following scenario:
- liba depends on libcore and gets linked as dylib
- libb depends on liba and libstd
When building liba, we need to already generate the __rust_abort symbol, but would conflict with the one from libstd. This is not a breaking change on most targets as due to what is arguably a bug in rustc, in this scenario rustc will report an error about libcore getting linked twice. If however you remove libstd.so or link for a target for which we don't ship libstd as dylib yet do still support dynamic linking (i don't know if any such target exists. maybe a wasm target?), then this scenario would currently work fine, but break with this PR.
Also cc @anforowicz for Chromium which bypasses the allocator shim. I think it will be fine for you as you include libstd, but I'm not sure if you don't have any no_std executables. It is probably more of an issue for Bazel.
Also cc @anforowicz for Chromium which bypasses the allocator shim. I think it will be fine for you as you include libstd, but I'm not sure if you don't have any no_std executables.
Thank you for the heads-up.
- I think it doesn't impact Chromium, because Chromium product builds link everything statically (no
dylibs, onlyrlibs that are at the end linked by non-rustc-driven linker). - OTOH we are currently working on building
stdinto adylibin developer builds (and later plan to expand this to some other libraries - e.g. thelogcrate). But this still seems ok, because I think that Chromium doesn't have a library likeliba(linked asdylib, but depends oncoreand not onstd). - That said, I don't fully understand the changes in this PR, so I defer to your judgement / I don't really understand if these changes may require a follow-up in Chromium when/if they get absorbed.
/cc @DKLoehr from the Chromium Toolchain team as FYI
Given core abort is essentially blocked on EIIs being ready, would it make sense to PR abort_immediate separately first?
I decided to rebase this branch/PR to just include abort_immediate, which is useful on its own. abort can be added later once EII can be utilized to do so properly.
View on GitHub
The job x86_64-gnu-gcc failed! Check out the build log: (web) (plain enhanced) (plain)
Click to see the possible cause of the failure (guessed by this bot)
For more information how to resolve CI failures of this job, visit this link.
library/core/src/process.rs
| 21 | /// # Platform-specific behavior |
|
| 22 | /// |
|
| 23 | /// `abort_immediate` lowers to a trap instruction on *most* architectures; on |
|
| 24 | /// some architectures it simply lowers to call the unmangled `abort` function. |
"unmangled" you mean libc::abort?
I adapted this wording from the panic-abort crate docs.
extern "C" { #[no_mangle] fn abort() -> !; } will be libc::abort in most cases, yes, but I'm not personally aware of what platforms have what behavior here.
gotcha. cc @japaric, this PR is heavily based on your panic-abort crate.
I don't think "unmangled abort" is very clear. Maybe refer to is as "the C abort function" or so.
Also, on which targets does this call libc::abort?
Sure, as just an unstable library API this seems fine
@bors r+ rollup
There's an unresolved comment further up. It's not blocking but @CAD97 please make sure to take care of it post-landing.
View all comments
Implements
core::process::abort_immediateas a wrapper aroundintrinsics::abort.(This PR used to also add
core::process::abort, but that's been deferred to a later addition.)