Tracking issue for `handle_alloc_error` defaulting to panic (for no_std + liballoc)
SimonSapin opened this issue · 90 comments
The proposal below was implemented in #76448, feature-gated under #![feature(default_alloc_error_handler)].
Issues to resolve before stabilization:
- Document the new behavior
- Get some usage experience beyond a synthetic test case #66741 (comment)
- The current implementation might have UB #76448 (comment) #66741 (comment)
Removing that unwind attribute needs to be benchmarked as it could lead to many extra unwind edges
Initial proposal:
Summary
This issue is for getting consensus on a change initially proposed in the tracking issue for #[alloc_error_handler]: #51540 (comment)
When no #[alloc_error_handler] is defined (which implies that std is not linked, since it literally has such a handler), alloc::alloc::handle_alloc_error should default to calling core::panic! with a message identical to the one that std prints to stderr before aborting in that case.
Although #51540 (comment) suggested that a full RFC would not be necessary, this is loosely structured after the RFC template.
Background
See the Background section of the sibling issue proposing stabilization of the attribute.
Motivation
As of Rust 1.36, specifying an allocation error handler is the only requirement for using the alloc crate in no_std environments (i.e. without the std crate being also linked in the program) that cannot be fulfilled by users on the Stable release channel.
Removing this requirement by having a default behavior would allow:
no_std+liballocapplications to start running on the Stable channelno_stdapplications that run on Stable to start usingliballoc
Guide-level explanation
When std is linked in an application, alloc::alloc::handle_alloc_error defaults to printing an error message to stderr and aborting the process.
When std is not linked and no other #[alloc_error_handler] is defined, handle_alloc_error defaults to panicking as if the following handler were defined:
#[alloc_error_handler]
fn default_handler(layout: core::alloc::Layout) -> ! {
panic!("memory allocation of {} bytes failed", layout.size())
}Reference-level explanation
The implementation for this would be very similar to that of #[global_allocator]. (Links in the next two paragraphs go to that implementation.)
alloc::alloc::handle_alloc_error is modified to call an extern "Rust" { fn … } declaration.
The definition of this function does not exist in Rust source code. Instead, it is synthesized by the compiler for “top-level” compilations (executables, cdylibs, etc.) when alloc is in the crate dependency graph. If an #[alloc_error_handler] is defined, the synthesized function calls it. If not, the synthesized function calls alloc::alloc::default_error_handler which is a new lang item. (Or is it?)
In order to allow experimentation for this new default behavior, it should initially be gated behind the #![feature(default_alloc_error_handler)] feature flag. When no handler is defined, a call to the default is (at first) only synthesized if any of the crates in the dependency graph has that feature gate. If none of them do, the current compilation error continues to be emitted.
Alternatives
The status quo is that no_std + alloc requires Nightly.
Stabilizing #[alloc_error_handler] or some other mechanism for specifying this handler is another way to unlock the no_std + liballoc on Stable use case. This removes the initial motivation for coming up with this default behavior. However perhaps this default is still desirable? In a no_std environment where there is no process to abort, the allocation error handler will likely be very similar to the panic handler (which is already mandatory).
Proposing FCP for deciding to adopt this approach:
@rfcbot fcp merge
Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:
- @Amanieu
- @Centril
- @Kimundi
- @KodrAus
- @SimonSapin
- @alexcrichton
- @cramertj
- @dtolnay
- @eddyb
- @joshtriplett
- @nikomatsakis
- @pnkfelix
- @scottmcm
- @sfackler
- @withoutboats
Concerns:
what if stable attributeresolved by #66741 (comment)
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
Stabilizing
#[alloc_error_handler]or some other mechanism for specifying this handler is another way to unlock theno_std+liballocon Stable use case. This removes the initial motivation for coming up with this default behavior. However perhaps this default is still desirable? In ano_stdenvironment where there is no process to abort, the allocation error handler will likely be very similar to the panic handler (which is already mandatory).
Should we still adopt this default behavior if the #[alloc_error_handler] attribute is to be stabilized soon?
@rfcbot concern what if stable attribute
What's the way forward here? Personally I would answer this simply with "yes":
Should we still adopt this default behavior if the
#[alloc_error_handler]attribute is to be stabilized soon?
I’m ok with that. I’ll make this not a blocking concern for now, but anyone feel free to discuss some more.
@rfcbot resolve what if stable attribute
What's the way forward here?
This proposal still needs at least 6 out of the 8 members of @rust-lang/lang and @rust-lang/libs who haven’t yet to approve it in #66741 (comment)
I personally do not have a mode of checking off my box here which aligns with what I feel. I do not think this is a good change to make and I personally lament the current state of the alloc crate where I do not believe it should have been stabilized in the first place. I would like to register a blocking objection for this but I do not have the time or the energy to do so. On one hand I would like to not be part of the critical path here so it can proceed without me, but as a member of the libs team I'm not sure that's possible.
Overall I feel that alloc has next-to-no leadership and is simply a result of "let's just ship what's there without thinking about it". This has led to very little documentation about how to use it effectively and fundamentally no actual way to use it ergonomically and effectively.
I don't feel strongly enough about this though to pursue a blocking objection, nor am I really that interested in trying to debate the finer points here. The alloc crate will haunt me no matter what whether I check off my box here or even if we decide to not go with this. Overall I feel stuck and don't know what to do. The best I can say is that I know rfcbot doesn't require full sign-off for entering FCP, so I'm going to not check my box off and assume that when enough of others have checked their box off it will proceed without me.
Cheer up Alex! It's not all that bad. While I would agree that there's some obvious bad parts to the alloc crate, I think that this particular change is extremely unlikely to cause any backwards compatibility concerns later on.
@alexcrichton Thanks for writing up your thoughts on this. I hear you on these concerns. What do you think of taking some time at the next Rust All Hands for @rust-lang/libs to discuss the crate organization of the standard library and such high-level design?
@alexcrichton that was my feeling for many years, but recently I've been pleased and impressed with the work on the alloc-wg (which, to be clear, I've only been a belated and minor contributor to, not trying to complement myself here!)
It looks like this RFC wasn't really done in consultation to that working group? Maybe the libs team could kick this over to them, and whatever their decision they could contextualize it in a more thorough long-term design you are interested in.
My personal opinion is that I don't like this RFC either, but if the allocator parameter stuff the working group has prototyped is merged it will matter a lot less as all no_std code can (and should) return alloc errors explicitly with Result giving the caller maximum flexibility to locally handle the error or punt and let the global handler deal with it. In other words, no_std code shouldn't be using this handler at all so I don't care so much how it works.
My understanding of https://github.com/rust-lang/wg-allocators is that it is not about everything allocation-related, but specifically about making it possible to use a non-global allocator with standard library containers. So the behavior of handle_alloc_error is not in scope for that working group.
giving the caller maximum flexibility to locally handle the error or punt and let the global handler deal with it […] no_std code shouldn't be using this handler at all
Box::new and many other existing APIs do call handle_alloc_error on errors and will keep doing so, including on no_std
My understanding of
That sounds right to me, but if you and/or the rest of the libs team wants to change the scope of the working group, they can. If @alexcrichton feels stretched thin, maybe that's something he'd want to pursue.
Box::newand many other existing APIs do callhandle_alloc_erroron errors and will keep doing so, including onno_std
That is right and I cannot change it. It is my opinion one ought to use Box::try_new_in instead. But it's just my opinion, and that hasn't landed yet, and so it remains to be seen whether or not core ecosystem crates will make the switch.
Even if you always used Box::try_new and Vec::reserve and all that, you'd still need an allocation error handler defined to link alloc into a no_std binary. So even if we encourage people to never call the allocation handler, we would need either this issue or the attribute issue to land for no_std binaries in Stable. Between the two options, I would urge the teams to accept this proposal because it is the minimal amount to stabilize while also allowing Stable no_std + alloc binaries.
My understanding of https://github.com/rust-lang/wg-allocators is that it is not about everything allocation-related, but specifically about making it possible to use a non-global allocator with standard library containers. So the behavior of handle_alloc_error is not in scope for that working group.
Agreed. IMO the alloc crate issues have nothing to do with wg-allocators, but instead to do with our story around no-std and support for diverse platforms that don't support all of std. It would be bizarre to link this issue to wg-allocators.
one concern with just panicking is:
Isn't it undefined behavior for the allocator functions to unwind?
What happens if the panic handler unwinds here?
The allocator is never supposed to call handle_alloc_error. it is intended entirely for code that tried an allocation and it failed and the code does not want to deal with the failure so it immediately ends the thread.
@Lokathor ah, ok. That makes sense.
Checking Centril's box as he's taking a break from the project.
🔔 This is now entering its final comment period, as per the review above. 🔔
The definition of this function does not exist in Rust source code. Instead, it is synthesized by the compiler for “top-level” compilations (executables, cdylibs, etc.) when alloc is in the crate dependency graph. If an #[alloc_error_handler] is defined, the synthesized function calls it. If not, the synthesized function calls alloc::alloc::default_error_handler which is a new lang item. (Or is it?)
That is a somewhat odd implementation strategy, and in particular it is not how the "default allocator" works that we use in std applications that do not set their own #[global_allocator]. What is the reason for using totally different implementation strategies for what looks like fairly similar mechanisms?
Synthesized code is much harder to read and maintain, so IMO we should keep it to an absolute minimum.
it is not how the "default allocator" works that we use in
stdapplications that do not set their own#[global_allocator]
Isn’t it? I meant to describe exactly the same mechanism.
No it's not. The default allocator is written in normal Rust code, not synthesized.
In particular, one advantage of having the default be normal Rust code is that it can also be used by Miri (instead of having to duplicate the logic, like we have to when codegen synthesizes this).
Oh I see. I did not mean that the logic of the default allocator is synthesized or that the logic of the handler would be, only that’s there’s a synthesized indirection somewhere. This is what enable liballoc and libstd to both be compiled before we make the decision whether to use libstd’s default allocator or not.
The alloc::alloc::alloc function calls a __rust_alloc symbol which is declared with extern { fn …; }. That function is synthesized at the LLVM level and does not have Rust source. It does nothing but forward the call to either __rdl_alloc for the default allocator or __rg_alloc for #[global_allocator]. __rdl_alloc has Rust source as you pointed out. __rg_alloc is synthesized at the AST level by #[global_allocator], which is similar to other built-in macros like format_args! or #[derive(Clone)]. It forwards the call to <THE_STATIC_ITEM as GlobalAlloc>::alloc.
Synthesized code is much harder to read and maintain
I agree, and now that I’ve typed out the above I think we can simplify it and get rid of LLVM-level synthesis:
#[global_allocator]would expand to aextern fndefinitions (like now) that define__rust_allocand friends directly, not__rg_alloc- We’d have a perma-unstable crate distributed with
libstdthat contains#[global_allocator] static A: std::alloc::System = std::alloc::System; - For “top-level compilation” that link
libstdbut no crate that defines a#[global_allocator], rustc would add this new crate to be linked.
#[alloc_error_handler] could work similarly. (Except the “real” default that panics would in a #[no_std] crate, and libstd would override it to abort.)
I imagine the AST emitted by built-in macros gets compiled to MIR like “normal” Rust source and can be interpreted by miri?
The alloc::alloc::alloc function calls a __rust_alloc symbol which is declared with extern { fn …; }. That function is synthesized at the LLVM level and does not have Rust source. It does nothing but forward the call to either __rdl_alloc for the default allocator or __rg_alloc for #[global_allocator].
Ah, that makes much more sense, thanks. :) If the default OOM hook follows the same pattern, that would work fine for Miri.
I imagine the AST emitted by built-in macros gets compiled to MIR like “normal” Rust source and can be interpreted by miri?
Correct, we don't even see that there was a macro involved.
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
The RFC will be merged soon.
The discussion starting at #66740 (comment) was resolved by closing #66740. As far as I can tell the next step here is an implementation PR.
#66741 (comment) discusses implementation strategies for the default #[global_allocator], that could also be used for a default #[alloc_error_handler]. (Slightly simpler since it’s a single function.)
Anybody already working on this, or is it worth starting a new PR?
I don't think anyone has started working on this yet. You can claim the issue by following these instructions.
Ok, #76448 implemented this and referenced this issue as a tracker.
What are the next steps to stabilization?
@rust-lang/libs We've already had an FCP for this, but that was before it was implemented. Do we need another FCP for the implementation or can we stabilize it right away?
I feel another FCP is not necessary, but some feedback from a "real" project (larger than a synthetic test case, perhaps embedded running on actual hardware?) trying this out would be good before stabilization.
For a call for embedded impl, it might be good to ping @adamgreig and @therealprof to nominate this for discussion at the next wg meeting, this could be a good focus project.
I also think the current implementation might be UB. Removing that unwind attribute needs to be benchmarked as it could lead to many extra unwind edges, I think.
Since the implementation PR points here as the tracking issue I’ve labelled it accordingly and added a before-stabilization checklist in the description.
Unwinding is pretty inherent to this proposal. But yeah it would be nice if we could somehow skip emitting those landing pad in the common case where the std crate is know to be in the dependency graph (since it overrides the default handler with one that does not unwind). Though that would only help if the relevant code paths of the alloc crate are inlined or maybe LTO’ed…
It seems a little surprising to me that linking in std would change the behaviour of the OOM hook, I would generally expect std to be a superset of the functionality of core + alloc + etc. If we can unwind on allocation failures with core, can't we unwind on allocation failures with std?
If std is left alone purely for backwards compatibility reasons, can we at least have a plan to bring the defaults back in-line with each other, perhaps in the next edition?
@Diggsey it's more like, std happens to implement the alloc-error handler in a way that never panics, so we'd like optimizations to exploit that. Crates using std cannot set their own handler because std already sets one.
Crates not using std can set their own handler, using an untsable feature. If they do not, they get a default. Or is your comment about the fact that that default is different from what std sets the handler too? Yeah I think I can see how that is kind of unexpected. (I first thought you were responding to @SimonSapin so I was confused.)
If std is left alone purely for backwards compatibility reasons, can we at least have a plan to bring the defaults back in-line with each other, perhaps in the next edition?
Editions are a per-crate thing while the handler is global for the crate tree, so editions do not help here.
note that in practice you can't unwind in just core, as provided by the Rust project, because there's no unwind mechanism provided in core. You're allowed to write your own, but that's not really the same of course.
Oh so the argument for the nounwind is that without std, there cannot be any uwninding, the panic will necessarily halt execution?
Or is your comment about the fact that that default is different from what std sets the handler too? Yeah I think I can see how that is kind of unexpected.
Yeah exactly.
Editions are a per-crate thing while the handler is global for the crate tree, so editions do not help here.
I don't think that's a problem, and I could be remembering wrong, but isn't this exactly how we handled changing the default allocator?
Ultimately one crate is the root, and that crate can determine the default handler based on its edition. (With an attribute to override the default that would be added automatically when you upgrade with cargo fix).
I am not aware that the default allocator is in any way related to the edition, but maybe I missed when that happened?
@RalfJung it would be more accurate to say that without std you don't get an eh_personality implementation provided, which does all the stack unwinding. Users are free to write their own, if they want, but in practice almost everyone just sets "panic = abort" in Cargo.toml and then gets on with things.
So you could unwind without std, and we can't break that, though few choose to.
I don't think we gain much from eliminating the OOM unwinding edges considering the allocator itself can already panic.
I would like std to eventually also transition to panicking instead of aborting on OOM since it gives applications a chance to handle OOMs and return an error. This is needed for libraries such as cURL that use Rust components and need to be robust when encountering OOM situations.
I don't think we gain much from eliminating the OOM unwinding edges considering the allocator itself can already panic.
The allocator is also marked #[rustc_allocator_nounwind]. Why do you say it can panic?
Ah actually it seems that the GlobalAlloc trait doesn't allow unwinding:
It's undefined behavior if global allocators unwind. This restriction may be lifted in the future, but currently a panic from any of these functions may lead to memory unsafety.
Looking through some old threads, it seems that allowing allocators to unwind does indeed cause some code size regressions: #42808
From #42808 (comment) it seems that most of the code size regression comes from unwinding edges from dealloc so we could only keep dealloc as nounwind while allowing the other allocator methods to unwind, including the OOM handler.
Unwinding on allocation failure is also incompatible with box expressions. They are lowered to _0 = Box(T);, and cannot affect a control flow.
That sounds like a detail of the current implementation rather than a characteristic of the language? And if that’s about the box keyword, it’s not stable so we can change anything about its behavior.
The liballoc uses box expression, so either lowering or liballoc should change to ensure it works correctly in the presence of unwinding.
Right now, there are quite a few pieces that assume that the alloc-err-handler will never unwind. So IMO the first step is to fix the documentation to match reality. If we want to permit unwinding handlers, that seems like a change that will have to affect quite a few places.
I hope this is not a stupid question, but what is the alloc-err-handler supposed to do then? I thought panicking would be a reasonable thing to do.
Not a stupid question at all. :)
It may panic as long as it does not unwind. So if one knows that panic leads to abort, then panic is fine.
What about defaulting to abort instead of panic then?
I just hope this will be on stable soon, because it is the only thing blocking alloc+no-std on stable.
Wait, I thought we’d already stabilized this. We have team consensus and an implementation.
It sounds like UB with unwinding is the only remaining issue? However:
- The
stdcrate defines a handler that aborts - The default handler proposed here only applies when no other handler is defined, which implies that
stdis not linked - Is it possible at all to unwind without
std? Is it possible on Stable? I believe at least the latter is no, since theunwindcrate is#[unstable]. Although that attributes does point to an open tracking issue: #32837.
If this UB cannot be triggered on Stable, should we open a new issue to track it and proceed with stabilizing this behavior?
Is it possible at all to unwind without std? Is it possible on Stable?
Is there some mechanism which ensures that for non-std binaries, the panic runtime is abort?
None, in fact I've seen at least one example (ever) with custom unwinding.
That requires unstable though, doesn't it?
But I could imagine the "regular" unwind runtime could be used on stable even without std... or maybe not, I do not know.
you can make a no_std bin on stable, though it's usually tricky to get right, and also I think it was never put in the release notes that you can do it.
I believe it can’t, that’s what I meant by the unwind crate is #[unstable].
I believe it can’t, that’s what I meant by the unwind crate is #[unstable].
-C panic=unwind works on stable though, so I am not sure if the stability of the crate is that relevant?
As far as I understand -C panic=unwind v.s. -C panic=abort is represented in compiler code by the PanicStrategy enum and controls:
- Whether code generation includes landing pads for unwinding
- Which of the
unwindorabortcrates gets linked, but only ifstdis also linked. (Technically, if a crate with the perma-unstableneeds_panic_runtimeattribute is linked.) This is implemented incompiler/rustc_metadata/src/creader.rs. These crates define symbols like__rust_start_panicbut don’t do anything unless called.
Compiling a crate with crate-type of bin, dylib, cdylib, or staticlib requires #[panic_handler] to be defined, either in that crate or in a recursive dependency. std defines one which eventually calls __rust_start_panic. If std is not linked it’s the program’s responsibility to define a #[panic_handler] that somehow never returns.
so can't the custom panic handler potentially unwind the stack?
On Stable it would get no help from the standard library to do it.
I don’t know what it takes re-implement unwinding. Probably a fair amount of platform-specific code, but that aside I don’t know if it’s possible without relying and unstable language features.
If std is not linked it’s the program’s responsibility to define a #[panic_handler] that somehow never returns.
Oh right, I forgot about that.
So... the safe thing to do would be to document that if #[panic_handler] unwinds, then #[handle_alloc_error] must be changed to not panic. The latter is impossible on stable; for the former we are not sure. But even if the former is not possible on stable this feels like something worth documenting.
It is currently not possible to support unwinding in no_std on stable because you need to define the eh_personality lang item and use intrinsics::try, both of which are unstable.
However I would like this to be supported eventually, so we should design handle_alloc_error with the goal of eventually supporting unwinding from alloc error handlers.
However I would like this to be supported eventually
I agree.
so we should design handle_alloc_error with the goal of eventually supporting unwinding from alloc error handlers.
I don't think that is a direct consequence; there is also the alternative of requiring the alloc error handler to not unwind or wrapping it in an abort-on-unwind shim.
If allocation truly can unwind, we'll have to get rid of the Box nullary operator and also carefully review all the nounwind LLVM annotations for allocation functions.
I think wrapping the panic in abort-on-unwind code is probably the best option, since I'm pretty sure I've written code that assumes allocation doesn't unwind for safety, and I'd guess I'm far from the only one.
May I unassign myself? I can't help much with the remaining issues, because I lack the time and knowledge.
@haraldh! No problem ❤️ Thanks for helping take it all this far.
So is our current decision point:
- Block stabilization on fixing the possible UB from unwinding in our allocation error handler so that when it is possible to unwind on stable in
no-stdwe're all good by:- Requiring that
#[alloc_error_handler]not panic, unless#[panic_handler]doesn't unwind - Rethink our assumptions made in the language and allocator infra so that unwinding becomes expected
- Requiring that
- Don't block stabilization on the unwinding issue since it's only possible on
nightlyanyways and sounds like it's not a common thing to do inno-std. Punt on whether unwinding should be supported.
The documented no unwinding requirement seems like a reasonable path to me, but this is out of my domain.
Right now, we don't have a solution, but what we'd be stabilizing wouldn't need a solution. Any solution we come up with would affect other cases which aren't being stabilized by this.
So probably the second option.
@Lokathor do you think there’s a single clear point where we’ll know that it’s becoming possible on stable to unwind while also being able to specify your own alloc error handler? If not I guess we run the risk of accidentally stabilizing with no decision having been made.
If you want to have unwinding you need to use the eh_personality language item, so as long as that's not stable then you can't unwind on stable. I'm not sure where to note that down though, i don't know of a tracker issue for that or anything.
At the very least, the code that marks the allocator functions as nounwind should have its comments extended to say that this is correct even for the default alloc_error_handler, because [all the things we discussed above].
Forgive me if I am missing something obvious, but couldn't we just abort if alloc error handler unwinds?
pub unsafe extern "C" fn __rdl_oom(size: usize, _align: usize) -> ! {
struct AbortOnUnwind;
impl Drop for AbortOnUnwind {
fn drop(&mut self) {
panic!();
}
}
let guard = AbortOnUnwind;
panic!("memory allocation of {} bytes failed", size)
}Under caveat of potentially being a 'clever' solution and not a perfectly ergonomic one. What if the standard distribution were to provide a crate, similar to alloc, which contains the default implementation of the oom error handler? As a std-internal one it can be annotated with any internal item including nounwind and being marked as a lang item for oom handling. The mechanism for using it would be a familiar one:
extern crate alloc;
// not w.r.t. bikeshedding
extern crate alloc_handler_std;And later, once the discussion on the stabilized form for writing those handlers has settled, users can customize it by replacing it with special oom-handling through another dependency. This method seems to have been accepted for panic handlers.
It’s no the handler definition that is annotated with nounwind but handle_alloc_error which calls it. So having a separate crate for an opt-in panicking handler does not help with the unwinding question.
Why don't we remove the explicit nounwind attribute from handle_alloc_error, and just make the compiler smart enough not to generate unwind edges if it knows they're not necessary?
As a first pass, this could just be special-cased in the compiler. Special casing is not ideal, but the extra unwind edges are purely a performance consideration, so this special-casing does not fundamentally change behaviour.
It’s no the handler definition that is annotated with nounwind but handle_alloc_error which calls it. [..]
I didn't meant to suggest that it must, but rather that one could add additional attributes—i.e. including some affecting llvm codegen, or for mir—if that turns out to be necessary for optimization/inlining purposes. Doing it via an external crate does not stabilize any symbol and this allows customizing either part of the interface in separate issues. It's essentially wraping this 'feature(_)` in an established syntax, such that it hopefully addresses some concerns of accidental stabilization? But it was just a random thought and I might be wrong.
Also note that this does not only affect embedded but also blocks some no_std + alloc x86 work of mine.
The current implementation might have UB
It wouldn't UB since abort_unwinding_calls MIR transform will ensure that unwinding through non-unwindable function will cause an abort.
Hello guys,
I am a Trezor hardware wallet firmware developer and I would be glad, if you stabilized no_std + alloc.
We rewrite our code base into Rust and using alloc simplifies things. Currently, I use nightly, but we would prefer to switch back to the stable Rust in production version.
🙏
Dear Rust developers,
After 1 year I would like to provide good reasons to resume the activities on this topic:
- During last year Rust embedded is becoming more relevant for productive application.
- An unstable compiler version is not acceptable for development of productive code.
- Dynamic memory handling is one topic where Rust can show important advantages to C/C++.
So I think this issue is really important for wider adoption rust in deeply embedded system.
So 🙏 🙏 🙏 find a way for no_std + alloc to stable rust.
This allows the opportunity to use Rust in my company. 😄
Isn't it a bit odd that the default alloc error handler with std aborts, but without std it panics and unwinds? Why does __rdl_oom not trigger an immediate-abort panic (similar to what happens when we unwind out of a nounwind function) and then that could be shared between std and no-std situations?
What’s an immediate-abort panic? Is it possible when "normal" panic unwinds? (As to why: I’d guess that distinction wasn’t a thing a decade ago and this wasn’t revisited since.)
It's a (fairly) recent thing. The panic info has a can_unwind field now which, if false, causes the panic machinery to always abort, never unwind. The entry point for that is panic_str_nounwind in core/src/panicking.rs.
Most no_std environments will set panic=abort anyway in the Cargo.toml, and anyone who doesn't might want the ability to catch the unwind and possibly do something to handle it.
It's probably the std handler that should be moved away from aborting, not the other way around.
There is already a -Zoom=panic flag. It isn't respected by this code however to switch between panic and panic_nounwind. Only libstd has code to determine which one to use.
It's probably the std handler that should be moved away from aborting, not the other way around.
Then that should happen in one fell swoop, not via a strange piecemeal stabilization.
Right now there's an incentive for people to go no_std on std-supporting targets just to get the panic no-abort OOM behavior, which is bad IMO.