Catching C++ std::exception in D

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Thu Nov 12 00:57:10 PST 2015


On 12 November 2015 at 07:50, Walter Bright via Digitalmars-d <
digitalmars-d at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20151112/d224ddde/attachment-0001.html>


More information about the Digitalmars-d mailing list