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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> So if the MI client, say in -stack-list-frames, asks for frames 0 - 3
Phil> the output would be:

Phil> 0
Phil> 1
Phil> 2
Phil> 3
Phil>   4
Phil>   5
Phil>   6

Phil> Because frame three has elided the next three frames -- it has to show
Phil> them to be consistent.  One side result of this is we have dispatched
Phil> to the my client seven frames instead of four frames.

I think that frames 4-6 should be children of frame 3.
So there will still be just 4 "top-level" frames.
It's been a while so perhaps I'm not remembering the approach properly.

Phil> One side effect is now the frame levels don't match up to the frames
Phil> levels requested.  Is this going to be a big issue for MI clients?

The main problem I can think of is that the MI client will expect to be
able to use the frame's id to select a frame.  We have to ensure this
works ok.

For anything else I think MI clients can adapt.

Phil> The other issue is now frame filters, regardless of what slice is
Phil> asked form has to process the whole stack (whereas before they just
Phil> started on frame_low of the requested stack).  This is because we have
Phil> to account for elided frames, and the consistency of output you noted
Phil> in your example (so even though we want frames 4 - 9, we still have to
Phil> start from frame 0, to see what has been elided before we get to our
Phil> slice).  This has a performance issues associated with for large
Phil> backtraces.

Correctness has to come first.

I guess it might be possible to ensure that we always start processing
on an appropriate boundary, perhaps by constraining the MI client to do
so.  This seems tricky though.  And, it seems like something we could
add later if we find we really need it.

Tom