This is the mail archive of the
mailing list for the GDB project.
Re: backtrace C-API
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Jason Molenda <jmolenda at apple dot com>
- Cc: Daniel Jacobowitz <drow at mvista dot com>,Gerrit Bruchhä user <gbruchhaeuser at gmx dot de>,gdb at sources dot redhat dot com
- Date: Tue, 22 Apr 2003 13:05:12 -0400
- Subject: Re: backtrace C-API
- References: <8ECA5848-745C-11D7-8838-000393D457E2@apple.com>
On Monday, April 21, 2003, at 02:04 PM, Andrew Cagney wrote:
On Fri, Apr 18, 2003 at 02:33:27PM +0200, Gerrit Bruchhäuser wrote:
is there any C-API function in libgdb.a (or some other library) which
returns a call stack (something 'bt' like)?
No; but you might find backtrace() useful if you're on a
But there probably should. How hard is it to create a `target-self' that uses local memory, and a jump-buf for registers? The tricky bit, I see, is the symbol table assuming a single global structure.
This falls into the category of Nasty Hack, but I helped someone on our compiler group with a similar problem a long time ago. I had them add a call at the site of interest which (a) got the current process' pid, (b) wrote a little gdb command script into a /tmp file which would attach to the process, bt, and detach, (c) ran system ("gdb --command=/tmp...") in the function, and (d) removed the file from /tmp.
I'm sure there are better ways to handle all this, but it took about five minutes to do all this correctly -- for a one-off problem, it wasn't a bad solution. They captured stdout, massaged the output a bit, and had the info they needed.
It's actually a well accepted technique. I first learnt about it on a
web page somewhere.