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

[Yao Qi <yao at codesourcery dot com>]

On 12/17/2013 12:19 AM, Pedro Alves wrote:
> In case of trace frame debugging, I don't think you can ever
> have a tailcall frame on top of a frame with unavailable
> stack, because dwarf2_tailcall_sniffer_first will throw
> an error computing prev_sp.  But even if that would work

Right, I find dwarf2_tailcall unwinder isn't selected for some tailcall
cases with an unavailable stack.

>> > 
>> > 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.  I don't see
any extra information the last sentence "Otherwise, xxxxx" delivered
except confusion.

-- 
Yao (éå)