Re: [objc] exception handling rewrite; gnu runtime operational

[Andrew Pinski <pinskia at physics dot uc dot edu>]

> 
> 
> > Andrew Pinski was kind enough to test this out on Darwin.  It showed
> > one buglet, which I fixed.
> > 
> > I've also stolen enough code from libstdc++ and libjava to implement
> > the exception handling backend bits in libobjc, so the one execute
> > test in the testsuite now passes with the GNU runtime.
> 
> Thanks!  This is *extremely* exciting! :-)
> 
> I'd like to have a look at the new exception handling system and see if we
> can update gnustep-base to use that exception handling system (when
> available) instead of sjlj - basically NS_DURING, etc would become
> wrappers of @try, etc.  That would be a nice test as we can then run
> plenty of software which is using exception handling and test that it
> works.
> 
> 
> > The Objective C "specification" document on Apple's web site is more
> > like "spec-lite".  It has nothing to say about how exceptions in the
> > language actually work.  My guess from looking at the pattern of
> > calls generated for the NeXT runtime is ObjC is more like Java than
> > C++ in that there are never nested or pending exceptions.  Thus there
> > is never a need to manage a stack of exceptions or anything.
> 
> This looks right - there is always at most one exception being thrown -
> you throw an exception, which unwinds the stack until a matching exception
> handler is found.  At that point, execution starts again normally in the
> exception handler.  The exception which was caught by the exception
> handler is accessible in the exception handler as a local variable, but
> disappears completely after the exception handler is finished, unless you
> throw it again.  It's quite simple and yes it is very similar to Java
> exception handling.
> 
> 
>  
> > I have not implemented the two calls needed by @synchronized.  I have 
> > no idea what sort of existing thread support exists in Objective C.
> 
> The GNU ObjC runtime provides a set of standardized functions which wrap
> the platform thread functions (this is the same as it happens now inside
> GCC itself).
> 
> 
> 
>