From: Phil Muldoon <pmuldoon@redhat.com>
To: Tom Tromey <tromey@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [patch][python] 2 of 5 - Frame filter MI code changes.
Date: Wed, 20 Feb 2013 15:17:00 -0000 [thread overview]
Message-ID: <5124E8EB.10009@redhat.com> (raw)
In-Reply-To: <87sj7dd3i7.fsf@fleche.redhat.com>
> Tom> How does this code strip off the first 'frame_low' frames?
>
> Phil> fi is unwound to the position of frame_low in a loop preceding this
> Phil> call. This is existing code, and not in the patch context.
>
> Tom> Also, Do frame_low and frame_high refer to "raw" or "cooked" frames?
> Tom> I tend to think they should refer to cooked ones, but I think at least
> Tom> the answer should be explicit and documented.
>
> Phil> In the existing mi sense, they just refer to frames on the stack. I
> Phil> followed this logic, but something I am still unsure of is if a frame
> Phil> is elided between frame low, and frame high, if that should be
> Phil> counted. I think it should.
>
> I see. I think this is wrong then. I think the arguments have to be
> applied after filtering. Here's why:
>
> One use for these arguments to the stack commands is so that a GUI can
> display just part of the stack, and then, if the user scrolls the
> display, it can request more of the stack to show. This way the GUI
> doesn't have to unwind the whole stack just to show the first 5 lines or
> whatever.
>
> Suppose you have a frame filter that notices a sentinel frame and then
> elides the following 3 frames. This isn't necessarily an obscure
> situation, maybe some interpreter takes a few function calls to
> implement a call in the interpreted language and the filter wants to
> collapse those frames to just show what is happening in the interpreted
> code.
>
> Suppose this sentinel frame occurs at stack position 3.
>
> Now suppose the MI client requests frames 0..4. Ok, the filter will
> work (since it can request more frames than the MI client did) and will
> present the right thing.
>
> But now the user scrolls the window and the MI client requests frames
> starting at frame 5.
>
> Whoops -- the output will be inconsistent; the filter won't trigger
> because the sentinel appears at frame 3, which the existing code already
> iterated past.
Ok I've adjusted in my local patch to align with your concerns, but I
wanted to make sure that we on the same page, and explore some things
that are a side result of this change.
So take this stack trace, I'll just use frame levels here for
illustrative purposes:
0
1
2
3
4
5
6
7
8
9
And in your example, we have a sentinel frame level 3, which elided
three other frames. So now our backtrace looks like:
0
1
2
3
4
5
6
7
8
9
So if the MI client, say in -stack-list-frames, asks for frames 0 - 3
the output would be:
0
1
2
3
4
5
6
Because frame three has elided the next three frames -- it has to show
them to be consistent. One side result of this is we have dispatched
to the my client seven frames instead of four frames. This might be
something the MI client is not expecting, but that is ok as you have
to turn on frame filters explicitly in MI, and we can assume that if
the client does that, they can know to expect this kind of behavior.
The next example is the client asking for frames 4 - 9. The output
will be
7
8
9
The client asked for 6 frames, but we delivered three. But that is
ok, as we noted above.
One side effect is now the frame levels don't match up to the frames
levels requested. Is this going to be a big issue for MI clients?
The other issue is now frame filters, regardless of what slice is
asked form has to process the whole stack (whereas before they just
started on frame_low of the requested stack). This is because we have
to account for elided frames, and the consistency of output you noted
in your example (so even though we want frames 4 - 9, we still have to
start from frame 0, to see what has been elided before we get to our
slice). This has a performance issues associated with for large
backtraces.
What do you think? Is this in line with your thoughts?
Cheers,
Phil
next prev parent reply other threads:[~2013-02-20 15:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 14:31 Phil Muldoon
2012-12-05 17:11 ` Tom Tromey
2012-12-07 13:56 ` Phil Muldoon
2012-12-10 21:03 ` Tom Tromey
2013-02-05 12:08 ` Phil Muldoon
2013-02-07 21:32 ` Tom Tromey
2013-02-20 15:17 ` Phil Muldoon [this message]
2013-02-20 20:37 ` Tom Tromey
2013-03-11 22:13 Phil Muldoon
2013-03-12 20:43 ` Tom Tromey
2013-03-12 20:52 ` Phil Muldoon
2013-03-13 12:15 ` Phil Muldoon
2013-03-13 17:48 ` Tom Tromey
2013-03-13 19:41 ` Phil Muldoon
2013-03-13 20:27 ` Tom Tromey
2013-03-13 20:53 ` Phil Muldoon
2013-03-13 20:56 ` Tom Tromey
2013-03-13 21:10 ` Phil Muldoon
2013-03-14 17:54 ` Tom Tromey
2013-03-14 19:35 ` Phil Muldoon
2013-04-22 16:01 Phil Muldoon
2013-04-26 11:19 ` Tom Tromey
2013-05-06 8:23 Phil Muldoon
2013-05-06 20:42 ` Tom Tromey
2013-05-07 8:23 ` Phil Muldoon
2013-05-07 14:02 ` Tom Tromey
2013-05-08 10:18 ` Phil Muldoon
2013-05-08 19:47 ` Tom Tromey
2013-05-10 10:45 ` Phil Muldoon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5124E8EB.10009@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox