Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Neo Jia <cjia@cse.unl.edu>
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 03:10:00 -0000	[thread overview]
Message-ID: <45383E0F.8000504@cse.unl.edu> (raw)
In-Reply-To: <3ef5826d0610191927n590c416fx238aa355a378d57c@mail.gmail.com>

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!


  reply	other threads:[~2006-10-20  3:10 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 [this message]
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
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=45383E0F.8000504@cse.unl.edu \
    --to=cjia@cse.unl.edu \
    --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