[PATCH] "tfind" across unavailable-stack frames.
Yao Qi
yao@codesourcery.com
Tue Dec 17 09:04:00 GMT 2013
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 (é½å°§)
More information about the Gdb-patches
mailing list