site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com That's not easy, for a bunch of reasons: o GDB's code is a complex tangled mess. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 22:45 -0800 1/2/07, Steve Checkoway wrote: In general, I agree. What we do in this specific case, is build a crash log including a backtrace (being very careful not to call forbidden functions), fork a new process, send the data to it and have it do things like symbol lookups and throw up a dialog informing the user of the crash, etc. If you're going to fork a new process, why not have the new process do the backtrace (vm_region, and so on, work just fine across processes). This has a bunch of benefits: o It minimises the amount of stuff that you have to do within the signal handler, which is always a good thing. o It makes it easier for you to write your backtrace code (you'll be able to call malloc, for example). o If the original process is dying, doing complex operations from within that process is a bad idea because you can't trust its state. At 0:01 -0800 2/2/07, Terry Lambert wrote: To get there from here, I can only tell you to look at the gdb sources, and see what gdb does for signal management for processes being debugged when it's compiled for Darwin/MacOS X. o GDB catches the standard crash exceptions (SIGSEGV, for example) as Mach exceptions, before the BSD part of the kernel turns these exceptions into signals. o For software signals, GDB tells the kernel to deliver the signal as an exception (it attaches using PT_ATTACHEXC). This email sent to site_archiver@lists.apple.com