-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Use only one personality function instead of 2 on Unix #34786
Comments
One possible route to an implementation is just using other off-the-shelf personalities, perhaps we could just use a C or C++ one so long as we can find it on all platforms. |
We actually already have most of LSDA parsing code here. Currently it's only used for x86_64-pc-windows-gnu. |
I think it'd be also fine to slowly bring platforms online with this strategy, for example we could test it out on 64-bit Linux first and then start doing the same change for other platforms and architectures. |
Implement ARM personality routine in Rust. Remove the `eh_personality_catch` lang item. Use a simplified version of `cfg_if!` in libunwind. Closes #34786
Right now we have two personality functions:
rust_eh_personality
rust_eh_personality_catch
The rationale is described in length here, but the gist is that we're currently "too lazy" to parse DWARF metadata, so we use
rust_eh_personality
for "all Rust functions in the world" andrust_eh_personality_catch
for the one function allowed to catch a panic. The former personality simply runs all cleanups, and the latter personality simply catches all Rust exceptions.This split makes it easy for us to define, but when a personality is run it should also have access to DWARF metadata about the call site it's running for. This metadata should indicate whether it's intended to catch or not, so we should in theory be able to read out the DWARF metadata and figure out what to do, allowing us to have one personality function instead of two.
The major downside of having two personality functions is that LLVM is unable to inline two functions that have different personalities. This unfortunately means that
catch_unwind
can have performance problems if we don't inline enough. We're currently using zero-cost exceptions on Unix, but what we're actually doing unfortunately isn't zero cost!This is only one piece of the puzzle towards fixing the performance issues mentioned, but it's an important one!
cc @vadimcn
The text was updated successfully, but these errors were encountered: