[libcxxabi] [libunwind] [llvm] [WebAssembly] Directly call EH personality function (PR #175202)

[Demetrius Kanios via cfe-commits]

QuantumSegfault wrote:

> I would like to know more about the context. What is D? Are you implementing exception support for [D language](https://dlang.org/)?

Sorry, yes. The D programming language. :)

> > 1. Same as with ObjC. Overriding `_Unwind_CallPersonality` does work, but only if we aren't linking with C++ causing conflicts.
> 
> Why does C vs. C++ matter for conflicts?
> > 2. D needs its own personality to handle its own type hierarchy, and it's ability to chain exceptions. Other than these language specific additions, it actually supports handling/catching C++ exceptions as well for interop with C++. Symbol conflicts are the problem here.
> 
> What symbol conflicts?
> 

C vs. C++? You mean D vs C++?

D requires it's own personality function. However right now LLVM is rigged to emit a call to `_Unwind_CallPersonality`, meaning that in order to change the personality, it has to be done globally for the whole programming, by redefining `_Unwind_CallPersonality` (or I guess, the actual `__gxx_personality_wasm0`). You can't attach a different personality per LLVM IR function (even if you tweak it to accept others) because it all goes through `_Unwind_CallPersonality`.

So for pure D programs, the necessary parts of `libunwind` can be redefined, including `_Unwind_CallPersonality` to internally call `_d_eh_personality` instead. But that means one can't link against true `libunwind` for compatibility with C++ exceptions.

> > 3. Right now I've got it working entirely independently of both `libcxxabi` and `libunwind` by reimplementing the small parts I need from `libunwind`. It would be nice to rely`libunwind` to define the necessary symbols (e.g. the `__cpp_exception` tag) to avoid conflicts and headache (especially with the exception tag), but we definitely don't need `libcxxabi` for a pure D project.
> 
> Why do you need `__cpp_exception` for D?

Both for interop with C++, and because the way I understand it, LLVM `catchpad`, `catchswitch`, etc. EH code lowers in terms of `__cpp_exception` only.

> > Dumb question, but why can't we just change the signature of the "personality" on Wasm? Make it take just that single exception pointer. `__gxx_wasm_personality_v0` is then defined the same as `_Unwind_CallPersonality`, forwarding to the internal implementation. Other languages can do the same, so long as they respect the implicit ABI requirements. Wouldn't that solve both problems (flexible personality, small code size)?
> 
> I'm not sure if I understand. Can you elaborate? What do you mean by the "personality" of Wasm? `__gxx_personality_wasm0`, or `_Unwind_CallPersonality`? Change whose signature to what?

What I'm suggesting, is make LLVM emit a call to to whatever the declared personality is for that IR function, but with the ABI expectations of `_Unwind_CallPersonality`. So this means either changing the signature of `__gxx_personality_wasm0`, or setting the EH personality of functions to `_Unwind_CallPersonality`.

The personality would take a single pointer, and be expected to prepare the landing pad context as necessary.

This would reintroduce the flexibility present on native platforms, without bloating each personality call-site.

https://github.com/llvm/llvm-project/pull/175202