public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: eliz@gnu.org
Cc: jan.kratochvil@redhat.com, gdb@sourceware.org
Subject: Re: Specify frame by address
Date: Sat, 29 Oct 2011 18:48:00 -0000	[thread overview]
Message-ID: <201110291843.p9TIhPoK012445@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <83ipn78ym5.fsf@gnu.org> (message from Eli Zaretskii on Sat, 29	Oct 2011 20:02:42 +0200)

> Date: Sat, 29 Oct 2011 20:02:42 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sat, 29 Oct 2011 19:46:38 +0200
> > From: Jan Kratochvil <jan.kratochvil@redhat.com>
> > Cc: gdb@sourceware.org
> > 
> > "address of the frame" is frame_id.stack_addr.  For DWARF it is CFA
> > (dwarf2_frame_cfa), which is for most arches just unwound SP (not PC!), that
> > is SP as shown by GDB in the caller.
> 
> Thanks.
> 
> What is it for stabs?  More generally, suppose I wanted to make the
> manual more clear on this matter, what could I tell the user about
> how to find out this address?

The debug info format isn't really relevant.  It's the architecture
that matters.  The address is typically the value of the stack pointer
just before doing the function call, or the value of the stack pointer
upon function entry.  We try to make sure that all unwinders agree on
the convention used, which is why for most architectures we use the
same convention as used by GCC for calculating the DWARF CFA, such
that the architecture-independent DWARF unwinder uses the same
convention as the architecture-specific unwinders that are used if no
DWARF debug info is available.

The frame address is printed by the "info frame":

Breakpoint 1, 0x000000000042b910 in main ()
(gdb) info frame
Stack level 0, frame at 0x7f7ffffbc350:
 rip = 0x42b910 in main; saved rip 0x42b761
 Arglist at 0x7f7ffffbc340, args: 
 Locals at 0x7f7ffffbc340, Previous frame's sp is 0x7f7ffffbc350
 Saved registers:
  rip at 0x7f7ffffbc348

So on amd64 the convention is that the frame address is the stack
pointer before the function call was made.

> > Such command really needs to iterate the frames and compare PC there.
> 
> Right.  I hoped that I could reference the frame by the PC address.

That wouldn't work.  Functions are sometimes called recursively, so
diffrerent frames may end up with the same PC address.

  reply	other threads:[~2011-10-29 18:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-29 17:47 Eli Zaretskii
2011-10-29 18:03 ` Jan Kratochvil
2011-10-29 18:04   ` Eli Zaretskii
2011-10-29 18:48     ` Mark Kettenis [this message]
2011-10-29 20:46       ` Jan Kratochvil
2011-10-30 13:21         ` Mark Kettenis
2011-11-02  9:14           ` Yao Qi
2011-10-30  6:39       ` Eli Zaretskii
2011-10-29 18:43 ` Andreas Schwab
2011-10-29 20:49   ` Eli Zaretskii
2011-11-01 18:58 ` Tom Tromey
2011-11-01 19:23   ` Eli Zaretskii

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=201110291843.p9TIhPoK012445@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).