This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch][python] 2 of 5 - Frame filter MI code changes.


 
> 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






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]