This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: frame->unwind->this_base()


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?

Display the frame's `virtual base pointer'.


>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.

Er,


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.

get_frame_base() returns ->frame and NOT ->id.base.


Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]