Re: [PATCH] "tfind" across unavailable-stack frames.

Pedro Alves
2013-12-16T16:25:18Z

On 12/16/2013 08:39 AM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
>> owner@sourceware.org] On Behalf Of Pedro Alves
>> Sent: Friday, December 13, 2013 6:50 PM
>
>
>> +/* See frame.h. */
>> +
>> +struct frame_id
>> +frame_id_build_unavailable_stack (CORE_ADDR code_addr)
>> +{
>> + struct frame_id id = null_frame_id;
>> +
>> + id.stack_status = FID_STACK_UNAVAILABLE;
>> + id.code_addr = code_addr;
>> + id.code_addr_p = 1;
>> + return id;
>> +}
>
> For record-btrace, we would also need to allow special_addr.
> I can also add another build function for this case.

Yes, quite similar to the one you were adding.

>> struct frame_info;
>> @@ -97,8 +115,8 @@ struct frame_id
>> function pointer register or stack pointer register. They are
>> wrong.
>>
>> - This field is valid only if stack_addr_p is true. Otherwise, this
>> - frame represents the null frame. */
>> + This field is valid only if frame_id.stack_status is
>> + FID_STACK_VALID. */
>> CORE_ADDR stack_addr;
>
> Maybe the comment should say that this field must be zero unless
> stack_status == FID_STACK_VALID.
>
> Frame_id_eq would compare stack_addr if stack_status compares
> equal.

Indeed. I'll do that. I had considered changing frame_id_eq
to only compare stack_addr if stack_status == FID_STACK_VALID,
but then since in practice we always centrally control what we
put in stack_addr, and put 0 zero anyway, might as well just
document that, and avoid ever seeing confusing garbage there.

Thanks,
--
Pedro Alves