Re: frame->unwind->this_base()

Andrew Cagney
2003-03-17T16:56:45Z

> 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