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