<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 November 2015 at 07:50, Walter Bright via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In order to interoperate with modern C++, it has been abundantly clear for some time that D needs some support for C++ exception handling:<br>
<br>
1. Have D finally blocks executed in D code that sits between a C++ try and catch<br>
2. Have C++ finally blocks executed in C++ code that sits between a D try and catch<br>
3. Be able to catch in D code an std::exception* or a C++ class derived from that.<br>
4. Throw an std::exception* from D code.<br>
<br>
That's the minimum credible support, and is likely all D will actually need.<br>
<br>
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:<br>
<br>
<a href="https://www.youtube.com/watch?feature=player_detailpage&v=Nglh-BExEus#t=227" rel="noreferrer" target="_blank">https://www.youtube.com/watch?feature=player_detailpage&v=Nglh-BExEus#t=227</a><br>
<br>
:-)<br>
<br></blockquote><div><br></div><div>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. :-)<br></div><div> <br></div><div>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.<br></div><br><br><br>Progress<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--------<br>
<br>
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.<br>
<br>
I'll pretty much have to generate .gcc_except_table myself, as well as redo how the finally and catch block code is generated.<br>
<br></blockquote><div><br></div><div>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.<br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Can Really Use Help<br>
-------------------<br>
<br>
I really appreciate the offers, and here's what will really help:<br>
<br>
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.<br>
<br></blockquote><div><br></div><div>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.<br><br></div><div>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...<br><br></div><div>--<br></div><div>Regards<br></div><div>Iain<br></div><div><br></div></div></div></div>