On 11/12/2015 2:08 AM, Iain Buclaw via Digitalmars-d wrote:
>     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'll have to check, but I'm pretty certain that libunwind will call the C++
> personality for you if you return `nothing found` from D personality function.

Why should it? What tells libunwind to call the C++ personality function? The generated EH tables only say call the D personality function.

On Thursday, 12 November 2015 at 10:09:10 UTC, Iain Buclaw wrote:
> On 12 November 2015 at 07:50, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>>
>> 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'll have to check, but I'm pretty certain that libunwind will call the C++ personality for you if you return `nothing found` from D personality function.

The personality function is in the landingpad metadata. Why would libunwind call the C++ one out of nowhere ?

On 2015-11-12 10:40, Walter Bright wrote:

> I don't anticipate that would be too difficult to add.

Great :)

-- 
/Jacob Carlborg

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

> On 11/12/2015 12:57 AM, Iain Buclaw via Digitalmars-d wrote:
>
>> I don't mind the compiler-specific personality,
>>
>
> gdc has one, __gcd_personality_v0. I don't see a way out of not having one.
>
>
Correct, there is no way out of having one.



> but a new throw function?  I
>> guess I should count my lucky stars that I'm still using the original
>> _d_throw
>> callback.
>>
>
> It only has a different name. Not a different API.
>
>
It's just more ABI differences between D compilers. ;-)

On 12 November 2015 at 11:17, deadalnix via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 12 November 2015 at 10:09:10 UTC, Iain Buclaw wrote:
>
>> On 12 November 2015 at 07:50, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>
>>
>>> 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'll have to check, but I'm pretty certain that libunwind will call the
>> C++ personality for you if you return `nothing found` from D personality function.
>>
>
> The personality function is in the landingpad metadata. Why would libunwind call the C++ one out of nowhere ?
>

I did say that I'd have to check.  :-)

In any case, I'm doubtful that forwarding to C++'s personality would work.

On 2015-11-12 11:37, Iain Buclaw via Digitalmars-d wrote:

> In any case, I'm doubtful that forwarding to C++'s personality would work.

Objective-C does that [1].

[1] http://www.opensource.apple.com/source/objc4/objc4-647/runtime/objc-exception.mm search for "__objc_personality_v0"

-- 
/Jacob Carlborg

On Thursday, 12 November 2015 at 06:50:31 UTC, Walter Bright 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.

I also started working on C++ exception handling for LDC/Calypso, I almost caught my first std::exception yesterday! (it went into the right catch and the IR looks right but _cxa_begin_catch() seems to return null instead of the exception object for some reason)

Clang and Calypso made the std::type_info stuff a breeze, getting the type_info value for any C++ type was one line of code.

I'll push the changes as is into a branch tonight, it's about ~400 lines.

> 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.

From what I gathered even if you manage to make the format of the LSDA tables compatible with __gxx_personality_v0, one blocker is that it still expects std::type_info pointers in the action table so will choke if it encounters D's TypeInfo_Class in there.

To check if a type_info from a catch clause handles the thrown exception it calls the virtual method type_info::__do_catch (which is what Calypso does too) so can't work with D classes.

Am Thu, 12 Nov 2015 11:31:39 +0100
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 12 November 2015 at 10:36, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
> 
> > On 11/12/2015 12:57 AM, Iain Buclaw via Digitalmars-d wrote:
> > 
> >> I don't mind the compiler-specific personality,
> >> 
> >
> > gdc has one, __gcd_personality_v0. I don't see a way out of not having one.
> >
> > 
> Correct, there is no way out of having one.
> 

To expand on this: I think we'd prefer one __d_personality_v0 which is implemented in upstream druntime and identical for all compilers.

Making the compilers ABI compatible is probably not a high priority, but OTOH we shouldn't introduce new ABI incompatibilities if possible.

Think of it this way: At some point it would be nice to have one, system-wide installed druntime shared library (from any compiler) and programs compiled with any other compiler should be able to use it. We've got well-defined name mangling primarily to allow this - but because of many small differences mixing compilers is not possible yet.

> 
> 
> > but a new throw function?  I
> >> guess I should count my lucky stars that I'm still using the
> >> original _d_throw
> >> callback.
> >> 
> >
> > It only has a different name. Not a different API.
> >
> > 
> It's just more ABI differences between D compilers. ;-)
> 

Johannes Pfau <nospam@example.com> writes:
> To expand on this: I think we'd prefer one __d_personality_v0 which is implemented in upstream druntime and identical for all compilers.

Speacking of upstream support.  GDC support SjLj exceptions.  In 2.067, it became obvious that Fiber needed separate SjLj context stacks which are normally thread specific.  I have a change in my iOS LDC fork which I suppose could go to upstream thread.d file so GDC can pick it up to.

https://github.com/smolt/druntime/commit/5d32e9e68cc6bd8b13cacfdb18a4d91374bf6b3e

See, I even included GNU_SjLj_Exceptions :-)

Sound like a good idea?  It is getting queued up soon as a PR to LDC once we get an iOS version officially in the compiler frontend.
-- 
Dan

On Thursday, 12 November 2015 at 16:55:09 UTC, Johannes Pfau wrote:
> To expand on this: I think we'd prefer one __d_personality_v0 which is implemented in upstream druntime and identical for all compilers.
>
> Making the compilers ABI compatible is probably not a high priority, but OTOH we shouldn't introduce new ABI incompatibilities if possible.

It should probably be based on the LDC implementation then, as it supports the most target platforms (Posix/libunwind, Win64/MSVC, iOS/SJLJ, and, as work in progress, Win32/SEH) and GDC's implementation is probably GPL-licensed (with runtime exceptions, but still definitely not Boost-compatible).

> Think of it this way: At some point it would be nice to have one, system-wide installed druntime shared library (from any compiler) and programs compiled with any other compiler should be able to use it. We've got well-defined name mangling primarily to allow this - but because of many small differences mixing compilers is not possible yet.

The biggest of which is probably that GDC and DMD disagree on parameter passing orders.

 — David