Date: Wed, 3 Aug 2005 18:21:27 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: cvs-src@FreeBSD.org Subject: Re: 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 ... Message-ID: <20050803181430.R23885@fledge.watson.org> In-Reply-To: <20050803124427.A65214@grasshopper.cs.duke.edu> References: <200508030427.j734ReCC049031@repoman.freebsd.org> <20050803123129.W16482@fledge.watson.org> <20050803124427.A65214@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@laposte.net> >>> Concept code from: Neal Fachan <neal@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050803181430.R23885>