This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] -stack-select-frame
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