Date: Fri, 24 May 1996 12:04:34 +0200 (MET DST) From: grog@lemis.de (Greg Lehey) To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: archie@whistle.com, freebsd-questions@freebsd.org Subject: Re: stack trace library? Message-ID: <199605241004.MAA08611@allegro.lemis.de> In-Reply-To: <199605230519.OAA07249@genesis.atrad.adelaide.edu.au> from "Michael Smith" at May 23, 96 02:49:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Michael Smith writes: > > Archie Cobbs stands accused of saying: >> >> Does there exist a library with routines that a program (linked with -g) >> can use for doing stack crawls? > > 'man nlist' may help. > >> For example, suppose you >> >> signal(SIGSEGV, CatchBug); >> >> Then when CatchBug() is called, you want the program to display a >> stack trace from the point at which the signal occurred, a la gdb's >> "where" command. Then we could have self debugging programs! :-) > > Note that it would probably almost as easy to fork off a subprocess, start > gdb and attach it to the offending process, run a few commands in it, > detach it and exit. I think it would be easier. I was thinking of doing something like this recently. One of the biggest problems people have in debugging multiple processes is that you can't easily debug a process started by another (non-shell) process. Sure, you can attach to the process (wonderful feature!), but you can't catch it from the start, and you can't catch it if it gets a fatal signal. It occurred to me that it would be relatively simple to add a couple of environment variables, say, "START_DEBUGGER" and "TRAP_DEBUGGER". crt0.o (the 'start' function which calls main ()) would look for START_DEBUGGER. If it found it, it would spawn the debugger specified as the value of the variable, and let it control it. TRAP_DEBUGGER would work similarly as a default trap handler for terminating a process. Instead of terminating the process, it would cause it to spawn a debugger and transfer control of the process to it. What do people think? I could hack up a prototype pretty quickly if there's enough interest (and no show-stopping conceptual problems). Follow up to -hackers, please. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605241004.MAA08611>