cvs commit: src/sys/alpha/alpha db_trace.c src/sys/arm/arm db_trace.c src/sys/conf files src/sys/i386/i386 db_trace.c src/sys/ia64/ia64 db_trace.c src/sys/kern subr_stack.c src/sys/powerpc/powerpc db_trace.c src/sys/sparc64/sparc64 ...

[Robert Watson]

On Wed, 3 Aug 2005, Andrew Gallatin wrote:

>>>  Added files:
>>>    sys/kern             subr_stack.c
>>>    sys/sys              stack.h
>>>  Log:
>>>   - Add support for saving stack traces and displaying them via printf(9)
>>>     and KTR.
>>>
>>>  Contributed by:         Antoine Brodin <antoine.brodin at laposte.net>
>>>  Concept code from:      Neal Fachan <neal at isilon.com>
>>
>> This sounds really great.  I have a local 
>> /usr/src/sys/kern/kern_utrace.c for back-tracing user application 
>> stacks that I find quite useful -- I wonder if we could extend this to 
>> also work with user thread stacks?  It can be quite handy for 
>> determining how an application reached a particularly obscure kernel 
>> state.  It doesn't do the ELF magic, but does reach into VM to 
>> determine what object+offset backs each page pointed to by a return 
>> address.
>
> How close is your kern_utrace.c to something that could be used to make 
> a (MacOSX like) crashreporterd deamon which saves application stack 
> traces when an application crashes?

Probably not very close.  I've primarily used it for console-based 
debugging.  Basically, at the machine-specific layer, all I provide is 
utrace_first_frame() and utrace_next_frame(), which return a series of 
struct utrace_frame structures, from which f_retaddr can be extracted.  I 
don't have the magic in place currently to allow tracing of non-current 
threads, although I've futzed with it in the past.

Then at the machine-independent layer, I have two high-level functions - 
user_stacktrace() and user_stacktrace_withmappings(), one of which prints 
out just the addresses returned by the MD layer, and the other which adds 
the VM wrapping magic that converts addresses into vnode+offset.

All of this is pretty specific to my environment and requirements, but it 
might be a starting point for something better.  What's missing is the 
nice cushy infrastructure, bundling of the trace data into useful blobs, 
etc.  I would like very much to see all this but haven't had time to 
follow up.

Robert N M Watson