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

This should be rather simple; you know it is C++ because of the metadata, and if you have access to RTTI (can just be hacked together with pragma(mangle, …)), you just do the type comparison then.

What has me quite a bit more worried is the lifetime handling involved in the usual "throw std::exception subclass by value, catch base class by reference" idiom. If I remember correctly, both GCC and Clang handle this by injecting a runtime function call into the end of the catch blocks. Their implementation must also support keeping the value around for rethrowing. At this point, I'm not aware of any fundamental incompatibilities, but it will certainly add to the complexity of the solution.

 — David

On Thursday, 12 November 2015 at 10:56:01 UTC, Jacob Carlborg wrote:
> 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"

ObjC doesn't do cleanup, so that's a bit different.

Am Thu, 12 Nov 2015 09:59:14 -0800
schrieb Dan Olson <gorox@comcast.net>:

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

Nice work. We certainly want that in GDC or even better in upstream. I guess we don't have a unittest yet which can detect this problem. Is it possible to add a unittest for this?

Johannes Pfau <nospam@example.com> writes:

> Am Thu, 12 Nov 2015 09:59:14 -0800
> schrieb Dan Olson <gorox@comcast.net>:
>
>> 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.
>
> Nice work. We certainly want that in GDC or even better in upstream. I guess we don't have a unittest yet which can detect this problem. Is it possible to add a unittest for this?

I had 2.067 unittest failures without this change, I don't recall which. I know it made me laugh becase exceptions were being thrown from Fiber A but being caught by Fiber B.  I can easily find out what fails by rerunning without the change. I'll report back later.

On 13 November 2015 at 18:45, Dan Olson via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> Johannes Pfau <nospam@example.com> writes:
>
> > Am Thu, 12 Nov 2015 09:59:14 -0800
> > schrieb Dan Olson <gorox@comcast.net>:
> >
> >> 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.
> >
> > Nice work. We certainly want that in GDC or even better in upstream. I guess we don't have a unittest yet which can detect this problem. Is it possible to add a unittest for this?
>
> I had 2.067 unittest failures without this change, I don't recall which. I know it made me laugh becase exceptions were being thrown from Fiber A but being caught by Fiber B.  I can easily find out what fails by rerunning without the change. I'll report back later.
>

There may be a few other holes between how Fibers and EH interact.

https://github.com/D-Programming-Language/druntime/commit/f6633abb43ea1f2464d3a772b8f8fe78216ffd8e

Dan Olson <gorox@comcast.net> writes:

> Johannes Pfau <nospam@example.com> writes:
>
>> Am Thu, 12 Nov 2015 09:59:14 -0800
>> schrieb Dan Olson <gorox@comcast.net>:
>>
>>> 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.
>>
>> Nice work. We certainly want that in GDC or even better in upstream. I guess we don't have a unittest yet which can detect this problem. Is it possible to add a unittest for this?
>
> I had 2.067 unittest failures without this change, I don't recall which. I know it made me laugh becase exceptions were being thrown from Fiber A but being caught by Fiber B.  I can easily find out what fails by rerunning without the change. I'll report back later.

I removed my SjLj change in core.thread to see what fails.

Running 2.067 unittests, std.concurrency fails with a memory access error.  Latest core.thread has a unittest for "Test exception chaining when switching contexts in finally blocks" that also fails with a memory access error.

On Friday, 13 November 2015 at 18:40:06 UTC, Iain Buclaw wrote:
> There may be a few other holes between how Fibers and EH interact.
>
> https://github.com/D-Programming-Language/druntime/commit/f6633abb43ea1f2464d3a772b8f8fe78216ffd8e

The SJLJ stack switching should probably be added to this mechanism.

 — David

Sorry for the delay, here's the initial commit for C++ exception catching in Calypso:

https://github.com/Syniurge/Calypso/commit/8b55ec1f013c29df86455ab055fbba91a72d92af
https://github.com/Syniurge/druntime/commit/d33d8bf32c739bf9a30705dfc764718c817f16b1

The main files of interest are:

https://github.com/Syniurge/druntime/blob/release-0.16.1/src/ldc/eh/cpp/gnu.d
https://github.com/Syniurge/Calypso/blob/master/gen/cpp/cppeh.cpp

And a basic example which segfaults at e.what() because __cxa_begin_catch returns null:

https://github.com/Syniurge/Calypso/blob/master/tests/calypso/eh/std_exception.d

Resulting IR : https://paste.kde.org/pvi2bokqx

catch (C++) were added to be able to catch any type, and that's the only cost for being able to catch any C++ exception and not just std::exception I think, Clang and the libstdc++ makes working with std::type_info very easy.

For the time the handler uses unwind-cxx.h copied from GNU's libstdc++ (it's an internal header which doesn't ship with any Ubuntu package). Its license is more permissive than the GPL, but if it isn't compatible it could be replaced by its libc++ equivalent.

David Nadlinger <code@klickverbot.at> writes:

> On Friday, 13 November 2015 at 18:40:06 UTC, Iain Buclaw wrote:
>> There may be a few other holes between how Fibers and EH interact.
>>
>> https://github.com/D-Programming-Language/druntime/commit/f6633abb43ea1f2464d3a772b8f8fe78216ffd8e
>
> The SJLJ stack switching should probably be added to this mechanism.
>
>  — David

I did a quick experiment to merge the two approaches and it failed in unittests.  I am not sure why yet.  They are implemented slightly different in that SjLj context is saved in the Fiber object, whereas _d_eh_swapContext is saving in a Thread.Context object.