Re: [PATCH] -stack-select-frame

[Daniel Jacobowitz <drow@false.org>]

On Fri, Jun 17, 2005 at 03:09:17PM +1200, Nick Roberts wrote:
>  > We've already got -stack-info-frame.  If you want to avoid
>  > -stack-list-frames, is it unreasonable to do the two round trips for
>  > -stack-select-frame / -stack-info-frame?  From Jason's measurements, it
>  > sounds like that isn't a problem.
> 
> -stack-info-frame hasn't been implemented yet (I've think we've been here
> before) but it would probably be quite easy to implement and I guess it
> could work like I've made -stack-select-frame without an argument work.

*snicker* that's what I get for reading the manual.  I assumed it was
implemented.

Maybe it is time to mark the unimplemented commands in the manual?

> However, the documentation suggests that it should work like "info frame",
> so perhaps its expected to have more information.

GDB Command
...........

The corresponding GDB command is `info frame' or `frame' (without
arguments).

I think we've got some leeway here.  I'd rather not expose the rest of
"info frame" to frontends without a demonstrated need.

>  > Not that it would be a terrible change to print out the frame.  It's
>  > just a question of whether there's benefit.  It'll make
>  > -stack-select-frame (again, only marginally) slower.
> 
> How about installing your second choice, just printing the frame when there is
> no argument?  I presume that when Apple use -stack-select-frame, it is always
> with an argument (doco will change to match):

If you're OK with only a literal "-stack-select-frame" providing the
frame information, how about implementing -stack-info-frame instead? 
The documentation for -stack-select-frame does not suggest the argument
is optional; we could make it mandatory.  It just seems cleaner to me
to have select be write-only and info be read-only.

> More generally I think it would be a good idea to mention in the manual
> that MI is still undergoing change to reduce the obligation to maintain
> legacy code.

I'm not real thrilled with doing this; we don't get to decide what
people do or do not use, so documenting things that people do use as
unstable does no one any favors.  However, I've been hearing a lot of
convincing points that we have more freedom here than I thought.  So
I'm getting more comfortable with changes.

-- 
Daniel Jacobowitz
CodeSourcery, LLC