library: Compute RUST_EXCEPTION_CLASS from native-endian bytes

[workingjubilee]

This makes it appear correctly in hexdumps on both LE and BE platforms.

As discussed extensively in https://github.com/rust-lang/rust/pull/130381/files#r1760034980

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
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

[thomcc]

Nice. Not going to rollup this in case it causes issues and is needed to be identified in a bisection.

@bors r+ rollup=never

[bors]

📌 Commit f21f4cd has been approved by thomcc

It is now in the queue for this repository.

[bors]

⌛ Testing commit f21f4cd with merge 150247c...

[bors]

☀️ Test successful - checks-actions
Approved by: thomcc
Pushing 150247c to master...

[rust-timer]

Finished benchmarking commit (150247c): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.3%	[-3.3%, -3.3%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-3.3%	[-3.3%, -3.3%]	1

Max RSS (memory usage)

Results (primary 2.9%, secondary -2.2%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.9%	[2.9%, 2.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.2%	[-2.2%, -2.2%]	1
All ❌✅ (primary)	2.9%	[2.9%, 2.9%]	1

Cycles

Results (primary -2.5%, secondary 6.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.8%	[6.8%, 6.8%]	1
Improvements ✅ (primary)	-2.5%	[-2.9%, -2.1%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.5%	[-2.9%, -2.1%]	2

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 771.075s -> 771.117s (0.01%)
Artifact size: 341.37 MiB -> 341.36 MiB (-0.00%)

[nbdd0121]

Note that the Itanium exception ABI says that the convention is that high bit are for vendor and low bits are for language: https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html.

Perhaps put a relnote to say that the langauge is now renamed to MOZ? ;)

[workingjubilee]

Note that the Itanium exception ABI says that the convention is that high bit are for vendor and low bits are for language: https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html.

Perhaps put a relnote to say that the langauge is now renamed to MOZ? ;)

✔️ MOZ from RUST

[RalfJung]

More like ZOM, no? "The low 4 bytes" would have a different order on little-endian than on big-endian.

If all other languages use from_be_bytes, then maybe we should, too?

[RalfJung]

Cc @rust-lang/libs

[purplesyringa]

Given that the class is changed anyway, should it be replaced with RUSTMOZ\0 for consistency?

[joshtriplett]

At the risk of bikeshedding, we could use RUSTRUST, since the vendor and language are now one and the same. :)

(Which doesn't do anything about endianness, but shrug.)

[RalfJung]

Given that the class is changed anyway, should it be replaced with RUSTMOZ\0 for consistency?

It's not changed, this PR just computes the same class in a different way.

EDIT: Ah sorry, I misremember the PR this is about.

[RalfJung]

Note that the Itanium exception ABI says that the convention is that high bit are for vendor and low bits are for language: https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html.

Perhaps put a relnote to say that the langauge is now renamed to MOZ? ;)

In other words, we are now deviating from the official spec. That should have been discussed a bit more before it is shipped, IMO.

[purplesyringa]

I would advise against RUSTRUST, as it counterintuitively forces Rust compilers that use another ABI to replace "RUST". IMO, keeping MOZ would be more correct.

[workingjubilee]

@RalfJung We've already left the building: The only MUST there is that the de facto string includes "C++\0" if one is a C++ implementation and conforms exactly to the C++ exception-handling semantics.

As we have never exactly done so, it doesn't particularly matter how we handle the string because a C++ implementation won't recognize our exceptions as C++ exceptions, and probably shouldn't.

[nbdd0121]

Except the Itanium C++ exception ABI is the de facto standard for all unwinding on Linux and it specifies that "low 4 bytes indicate the language"?

[workingjubilee]

Which is Rust, yes.

And here it says:

Set the exception_class field in the unwind header. This is a 64-bit value representing the ASCII string "XXXXC++\0", where "XXXX" is a vendor-dependent string. That is, for implementations conforming to this ABI, the low-order 4 bytes of this 64-bit value will be "C++\0".

That's a "will".

So our real choices are to either say we're C++... which, again, we've never done, would be somewhat unusual, and we don't really have any proof that it's a good idea... or not.

And at that point what matters is that if someone examines the value they won't find "C++\0" in it.

[workingjubilee]

alternatively, on the subject of vendor vs. language bytes:

    println!("{}", "🦀".len()) // 4

[nbdd0121]

It also says

The exception_class field is a language- and implementation-specific identifier of the kind of exception. It allows a personality routine to distinguish between native and foreign exceptions, for example. By convention, the high 4 bytes indicate the vendor (for instance HP\0\0), and the low 4 bytes indicate the language. For the C++ ABI described in this document, the low four bytes are C++\0.

And this what people do:

D sets it to DMD\0D\0\0\0: https://github.com/dlang/dmd/blob/4b94c9facf46a4167acfdc83ed9a92c5bc88c583/druntime/src/rt/dwarfeh.d#L139
GCJ sets it to GNUCJAVA (although this is no longer relevant because GCJ is dead).
GNAT sets it to GNU-ADA: https://github.com/gcc-mirror/gcc/blob/0b22f0585348335369298c7d39afd171758eebe9/gcc/ada/libgnat/s-excmac__gcc.ads#L84
Probably there're other examples in the wild.

This can be useful for telling people what foreign exception is caught when we eventually support catching them. I don't think we gain much for not following the convention here.

[workingjubilee]

Does anyone pattern match on the language names that aren't their own?

[workingjubilee]

It's a fairly trivial change, so I'm not particularly fussed by which... ah... end we want to start from. My main drive was to actually compute it from the string data it is (written backwards though it may be) instead of having an inscrutable constant.

By the way, the ABI docs mention HP\0\0 as the "example" vendor.

...the Itanium was bi-endian, and HP-UX uses big endian.

The "convention" they described was, yes, the one that makes sense on a big endian machine.

[RalfJung]

Does anyone pattern match on the language names that aren't their own?

I don't think that matters. There is an existing recommendation in the spec, and it is widely followed by implementations. We shouldn't diverge from that without a really good reason, and IMO we don't have a good reason.