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:

Tom> I'd prefer it if the various callers were changed to use mi_getopt.
Tom> This provides uniformity and lets us add options later.

Phil> If there was uniformity then I would agree, but as far as I looked
Phil> there wasn't.  Some MI commands use mi_getopt, some parse their own
Phil> options, some allow long options ("--"), others do not, and mi_getopt
Phil> does not handle long options in any case (and huge amounts of other
Phil> useful getopt functions too).  I wrote a patch for mi_getopts to
Phil> handle long options, but why do we even need another implementation of
Phil> getopt like functionality?

Ok, I see the problem now.

Right now, though. -stack-list-frames doesn't take any options.
I think it would be better if commands like this were converted to use
mi_getopt instead of doing the parsing by hand.
So I suggest having all the functions use a short option name.

I think the changes like in -stack-list-locals are strange, too, in that
they make options order-dependent.  This will be surprising to users.

Phil> I wanted to mention something else about MI.  I recently discovered in
Phil> the GDB manual that -stack-list-locals, -stack-list-arguments are
Phil> considered depreciated.  Not even sure if we should add frame filter
Phil> logic to them.  What do you think?

I think we still ought to.  It doesn't seem like much work and it is
friendlier in case some MI user hasn't updated.

Tom> I don't think I follow the high/low logic here.

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.

Tom