-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Make handle_alloc_error
default to panic (for no_std + liballoc)
#76448
Implement Make handle_alloc_error
default to panic (for no_std + liballoc)
#76448
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
962e10b
to
6379296
Compare
15e2e25
to
4bca7fa
Compare
Hmm, seems like
|
@nikomatsakis @Amanieu need some help here. |
or maybe @SimonSapin can help |
Under |
So, this one passes.
@Amanieu will try, thanks |
d77f320
to
5ac1d78
Compare
ready for review 😀 |
r? @Amanieu |
unsafe { | ||
__rust_alloc_error_handler(layout.size(), layout.align()); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For tests you can just do:
pub use std::alloc::handle_alloc_error;
This works since std
is imported by tests: https://github.com/haraldh/rust-1/blob/5ac1d7867411e1f28d3cee45df8c219fb39f414e/library/alloc/src/lib.rs#L146
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, changed
tcx.sess.err("`#[alloc_error_handler]` function required, but not found"); | ||
if !tcx.features().default_alloc_error_handler { | ||
tcx.sess.err("`#[alloc_error_handler]` function required, but not found."); | ||
tcx.sess.err("Use `#![feature(default_alloc_error_handler)]` for a default error handler."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be a note
or suggestion instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed to tcx.sess.note_without_error
a9efe49
to
8e46ce0
Compare
@bors r+ |
📌 Commit 8e46ce0d22b01bb32adc20b4e911f129da65ed44 has been approved by |
💔 Test failed - checks-actions |
target arm-unknown-linux-gnueabihf:
Hmpf... seems like I need help with my test cases... @Amanieu @SimonSapin ... they work on x86_64-linux ... no idea what is wrong here. |
It seems that this symbol is required on ARM. You can just define it as an empty function like here: https://github.com/rust-lang/compiler-builtins/blob/7b996ca0fa969199332d703b81fb411d85e5f7c4/examples/intrinsics.rs#L383 |
…balloc) Related: rust-lang#66741 Guarded with `#![feature(default_alloc_error_handler)]` a default `alloc_error_handler` is called, if a custom allocator is used and no other custom `#[alloc_error_handler]` is defined. The panic message does not contain the size anymore, because it would pull in the fmt machinery, which would blow up the code size significantly.
7de481e
to
cadd12b
Compare
@Amanieu thanks a lot for the link. I thought I messed up some unwind internals, which only show up on some architectures. Added those stubs. Let's see what is missing with the next bors run. |
@bors r+ |
📌 Commit cadd12b has been approved by |
…_reduced, r=Amanieu Implement Make `handle_alloc_error` default to panic (for no_std + liballoc) Related: rust-lang#66741 Guarded with `#![feature(default_alloc_error_handler)]` a default `alloc_error_handler` is called, if a custom allocator is used and no other custom `#[alloc_error_handler]` is defined.
☀️ Test successful - checks-actions, checks-azure |
@@ -82,4 +88,41 @@ pub(crate) unsafe fn codegen(tcx: TyCtxt<'_>, mods: &mut ModuleLlvm, kind: Alloc | |||
} | |||
llvm::LLVMDisposeBuilder(llbuilder); | |||
} | |||
|
|||
// rust alloc error handler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason you duplicated this code rather than adding a new entry to ALLOCATOR_METHODS
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, ok.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bjorn3 feel free to refactor the stuff without side effects
#[lang = "oom"] | ||
fn oom_impl(layout: Layout) -> !; | ||
} | ||
unsafe { oom_impl(layout) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that, unlike before, the #[alloc_error_handler]
is now allowed to unwind? There's no #[rustc_allocator_nounwind]
any more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, but __rust_alloc_error_handler
above still has #[rustc_allocator_nounwind]
. How is that not UB when it ends up calling __rdl_oom
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I blindly copied #[rustc_allocator_nounwind]
. Sorry. Remove it, if it is safe.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, or the other way round, I might have missed it.
|
||
// if there is a `#[alloc_error_handler]` | ||
#[rustc_std_internal_symbol] | ||
pub unsafe extern "C" fn __rg_oom(size: usize, align: usize) -> ! { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing like this exists for the allocator, right? There the generated __rust_alloc
etc symbols directly call the lang item? Looks like this is needed because the argument types differ; is there any plan to get rid of that mismatch (and the resulting two indirections through unknown extern
functions)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah no, the __rd
functions are just generated by the macro expansion code. That has the advantage that they do not themselves call an unknown extern
function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be removed, if compiler/rustc_codegen_llvm/src/allocator.rs
calls directly into the lang item, but with the extern "Rust"
API and a Layout
object reference.
I just didn't know, how to generate a extern "Rust" fn
in compiler/rustc_codegen_llvm/src/allocator.rs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the symmetric thing to do (when compared with #[global_allocator]
) would be for the #[alloc_error_handler]
attribute to generate __rg_oom
, but I guess it doesn't really matter.
It is just somewhat dissatisfying that the very same problem is solved three times in slightly different ways with various amounts of code sharing (global allocator, alloc error handler, panic handler).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the symmetric thing to do (when compared with
#[global_allocator]
) would be for the#[alloc_error_handler]
attribute to generate__rg_oom
, but I guess it doesn't really matter.It is just somewhat dissatisfying that the very same problem is solved three times in slightly different ways with various amounts of code sharing (global allocator, alloc error handler, panic handler).
I agree, but to implement it efficiently, I lack the expertise to redirect it via the rust ABI.
#[doc(hidden)] | ||
#[allow(unused_attributes)] | ||
#[unstable(feature = "alloc_internals", issue = "none")] | ||
pub mod __default_lib_allocator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this module name, given that this is not an allocator, but an alloc-error handler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
true
Related: #66741
Guarded with
#![feature(default_alloc_error_handler)]
a defaultalloc_error_handler
is called, if a custom allocator is used and noother custom
#[alloc_error_handler]
is defined.