Re: frame->unwind->this_base()

[Andrew Cagney <ac131313@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?

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