From: Michael Snyder <Michael.Snyder@palmsource.com>
To: Ashwin Bharambe <ashwinb@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Programmatic access to stack traces in C or C++ programs
Date: Fri, 20 Oct 2006 20:18:00 -0000 [thread overview]
Message-ID: <1161373317.9942.113.camel@localhost.localdomain> (raw)
In-Reply-To: <3ef5826d0610191927n590c416fx238aa355a378d57c@mail.gmail.com>
On Thu, 2006-10-19 at 22:27 -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..)
Can't be done in C (at least not without major hackery) --
you would have to write in assembler.
> 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.
Whatever you do would absolutely be architecture-dependent, and
ABI dependent (as it is in gdb).
> 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.
That would surely work - but as you say, it is 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.
I think that's pretty hopeless. But why don't you do it the easy way?
Just launch your program under gdb from the start, then use gdb
to put breakpoints at all the functions you are interested in.
You could write a script for that part. Then, at each breakpoint,
have gdb do this:
silent
backtrace
continue
Voila, you've got all your backtraces. And no overhead for forking.
next prev parent reply other threads:[~2006-10-20 20:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-20 2:27 Ashwin Bharambe
2006-10-20 3:10 ` Neo Jia
2006-10-20 3:13 ` Daniel Jacobowitz
2006-10-20 12:41 ` Ashwin Bharambe
2006-10-20 14:27 ` Daniel Jacobowitz
2006-10-20 20:18 ` Michael Snyder [this message]
2006-10-20 21:47 ` David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1161373317.9942.113.camel@localhost.localdomain \
--to=michael.snyder@palmsource.com \
--cc=ashwinb@gmail.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox