Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: frame->unwind->this_base()
Date: Mon, 17 Mar 2003 16:38:00 -0000	[thread overview]
Message-ID: <20030317163843.GA11494@nevyn.them.org> (raw)
In-Reply-To: <3E75F64B.5040700@redhat.com>

On Mon, Mar 17, 2003 at 11:22:35AM -0500, Andrew Cagney wrote:
> 
> >>However, shouldn't the only thing needing the `virtual frame pointer' / 
> >>get_frame_base() be the code that needs a virtual base pointer when 
> >>computing the value of a local variable?
> >
> >
> >Yes, and that's the only time that we search for the frame base.  But
> >what difference does it make?
> 
> (gdb) info frame
> 
> will display the correct value.

What does "correct" mean though?

> >At that point we have an offset that we
> >know is relative to DW_AT_frame_base, but we don't know if it's
> >relative to what the rest of GDB considers the frame base (since we
> >never use DW_AT_frame_base to compute the frame base in the first
> >place; and it's not clear to me that we should be).
> 
> Where, apart from `info frame', and variable evaluation, is it correct 
> for GDB to use the frame base?

I'm sorry, but I just don't understand what you're asking.  We use the
frame base all over.

The current frame base (i.e. id.base) is produced by target specific
code - often via prologue analysis; on x86-64 via CFI; etc.

The prologue analyzer, CFI code, etc. use the frame base when finding
saved registers, the saved PC value, et cetera.  For instance i386 uses
it to read the saved PC off of the stack.  This defines what GDB
expects to be the frame base.

The compiler doesn't necessarily have the same idea of the frame base. 
It can pick a convenient location, which may be biased some number of
words away from what GDB considers the frame base.  There's any number
of reasons this might happen.  Depending on, for instance, the
architecture's ABI and the available instructions for frame-relative
loads.

When using information computed by GDB we may need to use the current
frame base.  When using information provided by the compiler we
probably need to use the compiler provided frame base.

Are you saying that you want GDB always to use the DW_AT_frame_base? 
That's a bit of a leap from where we are today.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  reply	other threads:[~2003-03-17 16:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-16 22:04 frame->unwind->this_base() Andrew Cagney
2003-03-16 22:10 ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-17  0:09   ` frame->unwind->this_base() Andrew Cagney
2003-03-17  0:14     ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-17 16:22       ` frame->unwind->this_base() Andrew Cagney
2003-03-17 16:38         ` Daniel Jacobowitz [this message]
2003-03-17 16:56           ` frame->unwind->this_base() Andrew Cagney
2003-03-17 17:11             ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-17 18:20               ` frame->unwind->this_base() Andrew Cagney
2003-03-17 19:35                 ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-18  4:29                   ` frame->unwind->this_base() Andrew Cagney
2003-03-18  5:13                     ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-18 15:22                       ` frame->unwind->this_base() Andrew Cagney
2003-03-18 16:38                         ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-18 17:02                           ` frame->unwind->this_base() Andrew Cagney
2003-03-18 17:11                             ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-18 17:28                               ` frame->unwind->this_base() Andrew Cagney
2003-03-18 17:38                                 ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-18 20:22                                   ` frame->unwind->this_base() Andrew Cagney
2003-03-19 14:11                                     ` frame->unwind->this_base() Daniel Jacobowitz
2003-03-19 15:24                                       ` frame->unwind->this_base() Andrew Cagney
2003-03-19 15:32                                         ` frame->unwind->this_base() Daniel Jacobowitz

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=20030317163843.GA11494@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=ac131313@redhat.com \
    --cc=gdb@sources.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