site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com -tim _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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? This email sent to site_archiver@lists.apple.com