On 22 Feb 2009, at 10:24, Richard Frith-Macdonald wrote:
On 8 Feb 2009, at 11:42, David Chisnall wrote:
On 8 Feb 2009, at 06:47, Richard Frith-Macdonald wrote:
Actually, I take it back ... maybe we can recover from an uncaught
exception.
Problem is ... if we are using native exceptions ... by the time
the uncaught handler is called we have unwound the stack entirely
and the program has no way to continue running. But maybe the
native handling code can actually cope with that (or be changed to
do that).
I've been doing personality function hacking recently, so I'd be
happy to take a look at this if it's desired.
When the stack is unwound by native ('zero-cost') exceptions, the
unwind library calls the personality function twice for each
frame. The first time is to find the landing pad, the second time
is to perform the unwinding (call cleanup code in each intervening
frame and then continue unwinding).
For a while, I've been pondering adding the Étoilé resumable
exception stuff to the unwinding system. This would call the
unhandled exception function at the top of the stack, before
unwinding, and allow it to either call _Unwind_Resume() or
continue, depending on the exception.
It sounds like a good thing to have the option of resuming, even
though it's generally not advisable.
Do you have a patch for gcc/libobjc which would allow that?
It won't require patching gcc, just libobjc. I don't have a patch
currently, but I can probably create one fairly easily. It just
requires adding an optional trampoline in the throw function that will
bounce the exception out before unwinding the stack.
The current code in Étoilé allows exceptions to be either resumed or
restarted. Restarting jumps back to the start of the exception-
handling block and lets the code try again. This is currently done in
a really messy way. Ideally I'd want to make sure that the compiler
inserts an entry into the DWARF table pointing to the start of this
block and then let the unwind library walk back up the stack to find
it. This is a much bigger change, and one I won't have time to do for
a little while.
David
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
