Re: Stack trace queryable?
Re: Stack trace queryable?
- Subject: Re: Stack trace queryable?
- From: Sam Vaughan <email@hidden>
- Date: Fri, 7 Jan 2005 11:34:18 +1100
On 07/01/2005, at 7:05 AM, Greg Hurrell <email@hidden> 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));
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.
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.
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...
Sam
_______________________________________________
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