This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]