Skip site navigation (1)Skip section navigation (2)
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:  <199605241533.RAA24145@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?199605241533.RAA24145>