RFA: frame id enhancement
J. Johnston
jjohnstn@redhat.com
Thu Oct 16 19:06:00 GMT 2003
Andrew Cagney wrote:
>
>>> int
>>> frame_id_inner (struct frame_id l, struct frame_id r)
>>> {
>>> int inner;
>>> if (l.stack_addr == 0 || r.stack_addr == 0)
>>> /* Like NaN, any operation involving an invalid ID always fails. */
>>> inner = 0;
>>> else
>>> /* Only return non-zero when strictly inner than. Note that, per
>>> comment in "frame.h", there is some fuzz here. Frameless
>>> functions are not strictly inner than (same .stack but
>>> different .code). */
>>> inner = INNER_THAN (l.stack_addr, r.stack_addr);
>>> if (frame_debug)
>>> {
>>> fprintf_unfiltered (gdb_stdlog, "{ frame_id_inner (l=");
>>> fprint_frame_id (gdb_stdlog, l);
>>> fprintf_unfiltered (gdb_stdlog, ",r=");
>>> fprint_frame_id (gdb_stdlog, r);
>>> fprintf_unfiltered (gdb_stdlog, ") -> %d }\n", inner);
>>> }
>>> return inner;
>>> }
>>>
>>>
>>> does SPECIAL_ADDR add further ordering? If it doesn't then the
>>> comment needs to be updated (and the description in "frame.h"
>>> clarified).
>
>
>>
>>
>> Another good point. Yes, it does in this case. Two frames could both
>> not use the stack but one will definitely move the special_addr. I
>> need to add a SPECIAL_INNER_THAN macro which can default to false and
>> must be overridden by the platform.
>
>
> Is there real value add in having SPECIAL_INNER_THAN though? It would
> only be called by frame_id_inner. Looking at how that method is used:
>
>> frame.c:354: if (frame_id_inner (id, this))
>
> In frame_find_by_id: Its sole purpose is to act as a short circuit for
> the unlikely case where the ID isn't present in the frame. A stonger
> frame_id_inner has little value add.
>
>> frame.c:1909: && frame_id_inner (get_frame_id (this_frame),
>
> In get_prev_frame: Its a sainity check to detect what appears to be a
> badly corrupt stack. Marginal value add?
>
>> infrun.c:2094: && (frame_id_inner (get_frame_id
>> (get_current_frame ()),
>
> Commented out.
>
>> infrun.c:2383: if (frame_id_inner (current_frame, step_frame_id))
>
> Received a signal. Given that a predicate to the call is:
> && INNER_THAN (read_sp (), step_sp))
> the code's assumed that a signal modifies frame_id.stack_addr, so there
> is no value add. It might be useful to clarify this assumption though.
>
>> infrun.c:2477: && frame_id_inner (step_frame_id,
>
> It's the reverse of infrun.c:2383 where the inferior is falling out of a
> singnal trampoline, I think the assumptions again hold.
>
>> infrun.c:2641: if (!(frame_id_inner (current_frame, step_frame_id)))
>
> "Trust me" there's no value add. While the comment reads:
> /* In the case where we just stepped out of a function into the
> middle of a line of the caller, continue stepping, but
> step_frame_id must be modified to current frame */
> The test also updates step_frame_id when switching between frameless
> stackless leaf function. The extra test wouldn't fix that problem. I'll
> try to remember to add some comments to that code.
>
> Andrew
>
Ok, that simplifies things. I have included a revised patch that allows for the
wild-card scenario.
Ok?
-- Jeff J.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: frame-special.patch
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20031016/41e6bf1d/attachment.ksh>
More information about the Gdb-patches
mailing list