Chaining Mach exception handlers
Chaining Mach exception handlers
- Subject: Chaining Mach exception handlers
- From: "Timothy J. Wood" <email@hidden>
- Date: Thu, 30 Jun 2005 13:27:28 -0700
I'm working on upgrading OmniObjectMeter to work with 10.4
better. Part of the changes deal with dyld having changed its
notification method for when images are added and removed. It now
calls a little stub function which gdb sets a breakpoint on as a
signal to re-read the target's dyld image list.
This is all fine and good except that we _also_ have our own crash
catcher application, or the target application might also be running
in gdb, or any number of other exception handlers could be signed up.
Older versions of gdb used to have a mechanism where they'd catch
the exception and forward it on to the previously registered
exception handler. This is a ton of code and (a) it doesn't work if
the immediately previous handler doesn't want the exception type in
question (b) it doesn't seem to be in the current gdb source and (c)
it doesn't seem to work for me at all.
When I call exception_raise, using the previously registered
exception handler port, the exception *does* get sent to the next
handler, but exception_raise is not returning. I was expecting for
the chained handler to get called, return its result which would get
propagated back to the higher level handler via MiG, which it could
then return back to its caller (all the way back to the kernel
callout to the original handler).
Many years ago there was some discussion about having exception
handler chaining be easier. Did anything ever come of this?
-tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden