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

Pedro Alves
2013-12-17T10:09:29Z

On 12/17/2013 09:02 AM, Yao Qi wrote:
> On 12/17/2013 12:19 AM, Pedro Alves wrote:
>>>> What does the last sentence mean in the comments?
>>>>
>> The same comment is in frame_id_build. Re. what is means, see struct frame_id:
>>
>> /* The frame's special address. This shall be constant through out the
>> lifetime of the frame. This is used for architectures that may have
>> frames that do not change the stack but are still distinct and have
>> some form of distinct identifier (e.g. the ia64 which uses a 2nd
>> stack for registers). This field is treated as unordered - i.e. will
>> not be used in frame ordering comparisons.
>>
>> This field is valid only if special_addr_p is true. Otherwise, this
>> frame is considered to have a wildcard special address, i.e. one that
>> ^^^^^^^^^^^^^
>> matches every address value in frame comparisons. */
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> CORE_ADDR special_addr;
>
> The last sentence, especially "wildcard" stuff, is still confusing to
> me. Go through the usage of "special_addr", looks "special_addr" is
> used only if "special_addr_p" is true. Comment "This field is valid
> only if special_addr_p is true" is clear and sufficient.

It is clear, but it is not as precise or sufficient. A wild
card means that given these frame ids:

fid1: {code_p,stack_p,special_p}
fid2: {!code_p,stack_p,!special_p}

fid3: {code_p,stack_p,special_p}
fid4: {code_p,stack_p,!special_p}

{fid1, fid2} with same stack addresses,
and {fid3, fid4} with same code and stack addresses,
both:

frame_id_eq(fid1, fid2)
frame_id_eq(fid3, fid4)

return true.

> I don't see
> any extra information the last sentence "Otherwise, xxxxx" delivered
> except confusion.

The extra information indicates that e.g., frame_id_eq(fid3, fid4)
above returns true, not false, as one might at first expect.

Whether this whole wildcarding business is a good idea, is
another story.

--
Pedro Alves