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

[Pedro Alves <palves at redhat dot com>]

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