public inbox for gdb@sourceware.org
 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 00:14:00 -0000	[thread overview]
Message-ID: <20030317001407.GA20827@nevyn.them.org> (raw)
In-Reply-To: <3E75121F.4030405@redhat.com>

On Sun, Mar 16, 2003 at 07:09:03PM -0500, Andrew Cagney wrote:
> >On Sun, Mar 16, 2003 at 05:04:36PM -0500, Andrew Cagney wrote:
> >
> >>At present there is a per-frame ID method since different frames 
> >>determine their ID using different techniques.  The ID (which identifies 
> >>a given frame instance) includes a base and pc/func value.
> >>
> >>GDB's frame code also makes available the get_frame_base() method. 
> >>While the default implementation returns get_frame_id().base, I think 
> >>there is going to need to be a per-frame frame->unwind->this_base method.
> >>
> >>For dwarf2 frames, it would return, DW_AT_frame_base.  For prologue 
> >>frames, it would return an attempt at an equivalent value.  Hopefully it 
> >>wouldn't be called for other frame types :-).
> >>
> >>It might even be reasonable for a prologue based unwinder to error out 
> >>when asked for the frame's base before the stack frame has been created.
> >>
> >>Thoughts?
> >>
> >>I should note that dwarf2expr.c contains code that tries to 
> >>locally/directly evaluate the frame base.  I think that should instead 
> >>do a get_frame_base() call.
> >
> >
> >There's no guarantee right now that the DW_AT_frame_base agrees with
> >the frame's base.  I don't even think it's necessary that they be the
> >same.
> 
> There is certainly no guarentee that the DW_AT_frame_base and `struct 
> frame_id.base' match.
> 
> 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?  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).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2003-03-17  0:14 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     ` Daniel Jacobowitz [this message]
2003-03-17 16:22       ` frame->unwind->this_base() Andrew Cagney
2003-03-17 16:38         ` frame->unwind->this_base() Daniel Jacobowitz
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=20030317001407.GA20827@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).