Skip to content
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.

Sign up for GitHub

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

library: Compute Rust exception class from its string repr #130381

Merged
merged 1 commit into from
Sep 15, 2024
Merged

library: Compute Rust exception class from its string repr #130381

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 3 additions & 6 deletions library/panic_unwind/src/gcc.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -61,7 +61,7 @@ struct Exception {
pub unsafe fn panic(data: Box<dyn Any + Send>) -> u32 {
let exception = Box::new(Exception {
_uwe: uw::_Unwind_Exception {
exception_class: rust_exception_class(),
exception_class: RUST_EXCEPTION_CLASS,
exception_cleanup: Some(exception_cleanup),
private: [core::ptr::null(); uw::unwinder_private_data_size],
},
Expand All @@ -84,7 +84,7 @@ pub unsafe fn panic(data: Box<dyn Any + Send>) -> u32 {

pub unsafe fn cleanup(ptr: *mut u8) -> Box<dyn Any + Send> {
let exception = ptr as *mut uw::_Unwind_Exception;
if (*exception).exception_class != rust_exception_class() {
if (*exception).exception_class != RUST_EXCEPTION_CLASS {
uw::_Unwind_DeleteException(exception);
super::__rust_foreign_exception();
}
Expand All @@ -107,7 +107,4 @@ pub unsafe fn cleanup(ptr: *mut u8) -> Box<dyn Any + Send> {

// Rust's exception class identifier. This is used by personality routines to
// determine whether the exception was thrown by their own runtime.
fn rust_exception_class() -> uw::_Unwind_Exception_Class {
// M O Z \0 R U S T -- vendor, language
0x4d4f5a_00_52555354
}
const RUST_EXCEPTION_CLASS: uw::_Unwind_Exception_Class = u64::from_be_bytes(*b"MOZ\0RUST");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pre-existing, but should we really reverse the stored order between little-endian and big-endian systems? We currently show MOZ\0RUST on big-endian systems and TSUR\0ZOM on little-endian systems when interpreted as string/doing a hexdump.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed that when I poked at it. 👀 It is funny to me. All the other runtimes make the same mistake, so I initially decided not to change it. I think I wanted to actually look at the data through a hex dump before doing so.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe a relevant datapoint: windows-drivers-rs' wdk-alloc specifically chose u32::from_ne_bytes(*b"rust") for their allocator tag: https://github.com/microsoft/windows-drivers-rs/blob/c3b7c4aa06e43e928f27eb704f76932688802921/crates/wdk-alloc/src/lib.rs#L50

Copy link
Member

@RalfJung RalfJung Sep 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's not a mistake, maybe the type of this should be thought of as [u8; 8] rather than u64 -- with bytes always being interpreted left-to-right no matter the endianess.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current impl is a mistake if it should be interpreted as [u8; 8] as currently little endian systems put the string in reverse order, while big endian systems put it in the correct order.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, that would have to use from_ne_bytes... then transmuting back to a u8 array would always give the same results.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i assume it was just someone filling out the u64 literal in left to right order, as the previous comment described.

Copy link
Member Author

@workingjubilee workingjubilee Sep 26, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool, I checked the hexdump emitted and yeah, it is indeed backwards on x86-64. silly Rust.

Loading