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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
