This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Programmatic access to stack traces in C or C++ programs
- From: Daniel Jacobowitz <drow at false dot org>
- To: Ashwin Bharambe <ashwinb at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Thu, 19 Oct 2006 23:13:03 -0400
- Subject: Re: Programmatic access to stack traces in C or C++ programs
- References: <3ef5826d0610191927n590c416fx238aa355a378d57c@mail.gmail.com>
On Thu, Oct 19, 2006 at 10:27:08PM -0400, Ashwin Bharambe wrote:
> Hi all,
>
> I wanted to create a "stacktrace library" which would provide a
> routine to obtain the stacktrace of the program from any point
> _programmatically_ (like Java's stacktraces, for example..)
>
> I was aware of libc's non-standard stacktrace API but it did not quite
> work in many cases failing to resolve addresses, etc. It seems like
> stacktrace functionality is quite implementation and
> architecture-dependent. So, I was wondering if I could use portions of
> gdb's code to create such a library. Currently, to print a stacktrace,
> I utilize a piece of code (not mine, it's off the net) which fork()s a
> gdb sub-process, makes it ptrace the parent and run the command
> "backtrace". However this is quite time-consuming and sort of ugly.
Your best bet for reliability is to work with libunwind, if you can
restrict yourself to code with unwind information - which is more and
more practical nowadays.
> My question, therefore, is: are there pieces of the code I can steal
> from libgdb to make this happen programmatically. I tried some naive
> ways of performing gdb_init() and then having it execute the
> 'backtrace' command (by invoking backtrace_command directly, for
> example), however gdb says there's no stack. This seems to be the case
> because it does not initialize its data structures without starting a
> process.
>
> I would appreciate any pointers regarding how I can make gdb believe
> the current process is the one it should use, without really
> ptrace()ing it...
You can not readily do this. It will be easier and faster to stick
with forking another copy of GDB.
--
Daniel Jacobowitz
CodeSourcery