Re: [PATCH 7/9] gdb: remove VALUE_NEXT_FRAME_ID, add value::next_frame_id

Simon Marchi
2023-12-24T15:36:18Z

On 2023-12-22 12:06, Simon Marchi wrote:
>
>
> On 2023-12-22 12:02, Tom Tromey wrote:
>>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
>>
>> Simon> I'm not sure I understand, which function do you think should return a
>> Simon> frame_info_ptr?
>>
>> value::next_frame_id (though also with a new name).
>>
>> value::fetch_lazy_register can just access the frame_id directly if it
>> really needs to.
>>
>> I don't feel super strongly about this.
>
> Ah ok I see. Well, even value::fetch_lazy_register does call
> frame_find_by_id, so I guess it would make sense, it wouldn't be a
> pessimization.

So, there's one call in fetch_lazy_register that just wants the frame
id, the call on `new_val`. So I will leave it as is for now.

I had the idea of making it so that value::m_location stores a
frame_info_ptr to the next frame, instead of a frame id. Now that frame
infos are reinflatable, it should be safe to do so. And then we could
return a frame_info_ptr at no additional cost. But a first step
would probably be to convert the m_location union to a variant, because
we need the frame_info_ptr ctor and dtor to be called.

Simon