From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26125 invoked by alias); 17 Jun 2005 03:21:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26113 invoked by uid 22791); 17 Jun 2005 03:21:50 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 17 Jun 2005 03:21:50 +0000 Received: from drow by nevyn.them.org with local (Exim 4.51) id 1Dj7QT-0001j4-CO; Thu, 16 Jun 2005 23:21:49 -0400 Date: Fri, 17 Jun 2005 03:21:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] -stack-select-frame Message-ID: <20050617032149.GF17013@nevyn.them.org> Mail-Followup-To: Nick Roberts , gdb-patches@sources.redhat.com References: <17072.62436.183299.55978@farnswood.snap.net.nz> <20050616044209.GA5907@nevyn.them.org> <17073.5179.249482.402135@farnswood.snap.net.nz> <20050616132120.GA5277@nevyn.them.org> <17074.566.194312.713028@farnswood.snap.net.nz> <20050616234728.GA14260@nevyn.them.org> <17074.16093.924351.774111@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17074.16093.924351.774111@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00238.txt.bz2 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