On 12 November 2015 at 07:50, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

In order to interoperate with modern C++, it has been abundantly clear for some time that D needs some support for C++ exception handling:

1. Have D finally blocks executed in D code that sits between a C++ try and catch
2. Have C++ finally blocks executed in C++ code that sits between a D try and catch
3. Be able to catch in D code an std::exception* or a C++ class derived from that.
4. Throw an std::exception* from D code.

That's the minimum credible support, and is likely all D will actually need.

It's also clear that over the years nobody has risen to the challenge to get this working in dmd, so it falls to me to do it:

https://www.youtube.com/watch?feature=player_detailpage&v=Nglh-BExEus#t=227

:-)

Support for 1 and 2 already exists, and comes for free it you are using libunwind, all what is needed is a little assistance to make it realised. Though it also helps if you have some supporting backend to generate the magic EH handling for you too. :-)

Having your own EH tables has really left you with a shotgun wound in the foot here. I suspect this is the real reason why no one has stepped up.

Progress

--------

I have started by switching from generating .debug_frame sections to .eh_frame sections. It appears that gcc/g++ already do this, and .debug_frame is now obsolete.

I'll pretty much have to generate .gcc_except_table myself, as well as redo how the finally and catch block code is generated.

Good luck! Just a small request to on my side to not introduce anything in the frontend! I don't want a repeat of __va_argsave where gdc had supported 64bit for years and years.

Can Really Use Help
-------------------

I really appreciate the offers, and here's what will really help:

Writing the druntime end of things, which is really providing just two functions: d_throw (d_dwarf_throw to distinguish it) and the libunwind personality function: __dmd_personality_v0. The tricky part with the personality function will likely be recognizing std::exception* exceptions. I wonder if forwarding the call to __gxx_personality_v0 will work.

I don't mind the compiler-specific personality, but a new throw function? I guess I should count my lucky stars that I'm still using the original _d_throw callback.

You will be able to recognize whether or not the exception object comes from C++, unwind's exception_class field can be compared to some gxx_exception_class enum value (or const symbol). Getting the typeinfo of the C++ exception is straightforward too. In the EH table, I guess you will have to generate an extern reference to C++'s typeinfo object somehow...

Regards

Iain