site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On 07/01/2005, at 7:05 AM, Greg Hurrell <greg@hurrell.net> wrote: El 04/01/2005, a las 23:27, Sam Vaughan escribió: I haven't looked at the MoreBacktrace code, but you should be able to generate backtraces pretty simply with the following code: Thanks a lot, Sam. The MoreBacktrace sample uses the same assembly to get the stack pointer: #define MoreBTPPCGetStackPointer(result) \ __asm__ volatile("mr %0,r1" : "=r" (result)); One thing that interests me is that both implementations seem to be designed to get the stack trace of the current thread. I wonder what would be necessary to get a stack trace of all threads in a running process. Sam _______________________________________________ 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... But the code is a lot more complicated than yours. Well it was probably written by someone like Quinn who knew what they were doing and guarded themselves better against all the possible pitfalls ;-) I wrote that quickly, found that it worked and have only used it in the narrow environment of kernel debug code, so be careful. If it's user space threads you're interested in, then you should be able to start with the source code to "top". I seem to recall there are some useful user space APIs being used there to get thread information, although program counter addresses might be asking too much. I guess what you're really looking for is the source code to Sampler.app. I wonder if there's an open source equivalent. I wrote a tool a while ago to get symbolic backtraces on all the running kernel threads on a live system. It's very handy for quickly finding deadlocked kernel threads without setting up dual machine debugging - ideal for deadlocked test machines on the other side of the world. It uses a kext made up of two halves, one compiled against Mach headers and the other against BSD. The BSD side contains the sysctl interface and memory allocation code, and the Mach side walks the running threads and pulls out the program counters and stack traces. It works, but I think it'll become unmaintainable in 10.4. I haven't got around to formally requesting an API for it yet... This email sent to site_archiver@lists.apple.com