Re: Programmatic access to stack traces in C or C++ programs

["Ashwin Bharambe" <ashwinb@gmail.com>]

Sweet. Thanks Daniel for pointing me to libunwind.. Now, given the
instruction pointer and stack pointer values, do you think I can use
some parts of gdb code to dump out a more readable version of the
stackframe? It would be _really_ nice if I could dump out argument
values as well, but I suspect that might be much harder.

Ashwin

On 10/19/06, Daniel Jacobowitz <drow@false.org> wrote:
> 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
>


-- 
Ashwin Bharambe,  Ph.D. Candidate, Carnegie Mellon University.
Office: 412-268-7555            Web: http://www.cs.cmu.edu/~ashu