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

Neo Jia cjia@cse.unl.edu
Fri Oct 20 03:10:00 GMT 2006


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. 
I think the stack backtrace should be arch. dependent. So, your lib 
should be also arch. 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.
>
> 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.
My suggestion is to read the document of each arch. especially the ABI 
for each arch. Then you might know
where is the stack frame pointer then you can quite easy to dump it 
back. You might need to pay attention to those
code compiled with omit frame pointer option.

Another interesting thing for you, google has a project called 
"coredumper". http://goog-coredumper.sourceforge.net/

Thanks,
Neo
>
> 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...
>
> Thanks very much for reading the long message!
> Ashwin
>


-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!



More information about the Gdb mailing list