"David Nadlinger" <code@klickverbot.at> writes:

> On Tuesday, 8 April 2014 at 18:55:35 UTC, Brad Roberts wrote:
>> I think, for a mixed language application, that the important part is proper object lifetime management more than being able to catch exceptions from different languages.  When unwinding a c++ exception that has stack frames intermixed with D, destructors need to be executed appropriately, and vice versa.
>
> I haven't actually tried to do this, but in theory, this should be the easy part with libunwind. You just ignore foreign exceptions during the search phase (i.e. not catch them), and during the unwind phase, your own personality function is called again for cleanup regardless of the handler the stack actually unwinds to.

I tried handling foreign exceptions back in Feb with the sjlj personality function I am using in LDC for iOS.  Well, at least doing cleanups so that a objc/c++ exception could bubble up and D could call dtors and finally blocks.  It was mostly working but I wanted to make progress on other stuff so shelved it since I had normal D sjlj eh working.
-- 
Dan

On 2014-04-09 10:27, David Nadlinger wrote:

> So, in the last paragraph, you are specifically referring to DMD on x86_64?

x86_64 yes, not necessarily only for DMD. I thought if DMD, LDC and GDC all used the same exception handling model and the same as C++ it would be easier. Especially for implementing support for Objective-C exceptions, which is why initially started this thread.

I don't know which exception model iOS 64bit uses for Objective-C. If it uses the C++ exception model it would apply for that platform as well.

-- 
/Jacob Carlborg

On 2014-04-09 11:52, Iain Buclaw wrote:

> The "middle-ground" would be us handling Objective-C foreign
> exceptions in our EH personality function.

Yes, exactly.

-- 
/Jacob Carlborg

On Wednesday, 9 April 2014 at 16:48:54 UTC, Jacob Carlborg wrote:
> x86_64 yes, not necessarily only for DMD. I thought if DMD, LDC and GDC all used the same exception handling model and the same as C++ it would be easier. Especially for implementing support for Objective-C exceptions, which is why initially started this thread.

They don't. GDC and LDC use libunwind, whereas DMD uses its own custom EH implementation.

With GDC and LDC, you'd just need to add your code to handle Objective-C exceptions to the personality functions. libunwind exceptions have a "type"/"source language" field, and by default most implementations either ignore unknown exception types or abort on encountering them.

David

On 2014-04-09 19:27, David Nadlinger wrote:

> They don't. GDC and LDC use libunwind, whereas DMD uses its own custom
> EH implementation.

That's what I want then, for all implementations to use libunwind.

> With GDC and LDC, you'd just need to add your code to handle Objective-C
> exceptions to the personality functions. libunwind exceptions have a
> "type"/"source language" field, and by default most implementations
> either ignore unknown exception types or abort on encountering them.

That's what I was hoping.

-- 
/Jacob Carlborg

On 2014-04-09 17:27:55 +0000, "David Nadlinger" <code@klickverbot.at> said:

> On Wednesday, 9 April 2014 at 16:48:54 UTC, Jacob Carlborg wrote:
>> x86_64 yes, not necessarily only for DMD. I thought if DMD, LDC and GDC all used the same exception handling model and the same as C++ it would be easier. Especially for implementing support for Objective-C exceptions, which is why initially started this thread.
> 
> They don't. GDC and LDC use libunwind, whereas DMD uses its own custom EH implementation.
> 
> With GDC and LDC, you'd just need to add your code to handle Objective-C exceptions to the personality functions. libunwind exceptions have a "type"/"source language" field, and by default most implementations either ignore unknown exception types or abort on encountering them.

Maybe the right course of action would be to just ignore Objective-C exceptions in 64-bit DMD and finish the rest of D/Objective-C. The day D/Objective-C is ported to GDC and LDC, it should be much easier to make exceptions work there.

The funny thing is that within Cocoa exceptions are usually reserved for logic errors (array out of bound, method calls with unknown selector, assertion errors, etc.). That's the kind of error we consider unrecoverable when they happen in D code. So I think people can manage without Objective-C exceptions for some time.

Given what I wrote above, I'll also argue that it's not a wise move to support exceptions in D/Objective-C with the legacy runtime even though I implemented it. Because the legacy runtime uses setjmp/longjmp for exceptions, try blocks in a function that calls extern(Objective-C) functions are costly. And the compiler has to implicitly add those costly try blocks to wrap/unwrap exception objects to prevent unwinding of the wrong kind from leaving the current function. It was fun to implement, but it's also the most intrusive changes D/Objective-C makes to the frontend, and a big parts of the additions to druntime.

If we plan to support mixed unwind mechanisms some day it might be useful to keep, because the logic for bridging between two or more unwinding systems is all there. Otherwise I'd probably scrap the whole exception wrapping/unwrapping thing. I doubt the performance cost is worth it, and I doubt the maintenance cost for the additional complexity is worth it. The legacy Objective-C runtime is mostly gone from Apple's ecosystem anyway.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

Am Wed, 9 Apr 2014 15:32:56 +0100
schrieb Iain Buclaw <ibuclaw@gdcproject.org>:

> On 9 April 2014 14:54, Marco Leise <Marco.Leise@gmx.de> wrote:
> > Am Wed, 9 Apr 2014 23:11:08 +1000
> > schrieb "Daniel Murphy" <yebbliesnospam@gmail.com>:
> >
> >> You could always go the other way and change GDC and LDC to match what DMD does. :)
> >
> > And precisely that is not always possible. E.g. GCC developers have decided against "naked" asm functions. And this
> 
> Naked exists, just not for x86.  :o)

That slipped my mind, possibly because I still think of D as a programming language for x86 (like Delphi).

> > A common ground has to be found that likely changes the ABI in all 3 compilers. DMD is actually least restricted by the lack of vetoing "upstream" developers :)
> >
> 
> I have only vetoed features that are tied to a specific architecture. This is not unreasonable in my eyes.

I meant upstream more literally than I made it look. I.e. even if everyone involved with D found some ABI detail a good idea, it could be that the required changes to the backend, like naked asm for x86 cannot be made by you or David, but require the good will of the core team of the respective backend.

And yes, it is good to now and then look beyond x86. The developments were in favour of D it seems. 16-bit chips dimish, TLS became available on Mac OS X. Possibly later Walter's "better C" will be discussed again to not overload simple platforms with GC, exceptions and TLS :)

-- 
Marco

Am Wed, 09 Apr 2014 17:27:55 +0000
schrieb "David Nadlinger" <code@klickverbot.at>:

> They don't. GDC and LDC use libunwind, whereas DMD uses its own custom EH implementation.

Is libunwind somehow copied verbatim in the GDC/LDC sources? Because I'm pretty sure I only installed it 2 weeks ago when some benchmark tool from Google asked me to install it.

-- 
Marco

On Wednesday, 9 April 2014 at 21:19:46 UTC, Marco Leise wrote:
> Am Wed, 09 Apr 2014 17:27:55 +0000
> schrieb "David Nadlinger" <code@klickverbot.at>:
>
>> They don't. GDC and LDC use libunwind, whereas DMD uses its own custom EH implementation.
>
> Is libunwind somehow copied verbatim in the GDC/LDC sources?
> Because I'm pretty sure I only installed it 2 weeks ago when
> some benchmark tool from Google asked me to install it.

The implementation is part of the runtime libraries shipped by GCC (and installed by default on every system).

David

On 9 April 2014 23:55, David Nadlinger <code@klickverbot.at> wrote:
> On Wednesday, 9 April 2014 at 21:19:46 UTC, Marco Leise wrote:
>>
>> Am Wed, 09 Apr 2014 17:27:55 +0000
>> schrieb "David Nadlinger" <code@klickverbot.at>:
>>
>>> They don't. GDC and LDC use libunwind, whereas DMD uses its own custom EH implementation.
>>
>>
>> Is libunwind somehow copied verbatim in the GDC/LDC sources? Because I'm pretty sure I only installed it 2 weeks ago when some benchmark tool from Google asked me to install it.
>
>
> The implementation is part of the runtime libraries shipped by GCC (and installed by default on every system).
>

Just look for something like  /usr/lib/gcc/<xxx>/<x.x>/include if you've installed the libgcc-dev files.