From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13943 invoked by alias); 16 Jun 2005 23:20:58 -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 13892 invoked by uid 22791); 16 Jun 2005 23:20:39 -0000 Received: from lakermmtao09.cox.net (HELO lakermmtao09.cox.net) (68.230.240.30) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 16 Jun 2005 23:20:39 +0000 Received: from white ([68.9.64.121]) by lakermmtao09.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050616232036.EXDH6804.lakermmtao09.cox.net@white>; Thu, 16 Jun 2005 19:20:36 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1Dj3f3-0006Ad-00; Thu, 16 Jun 2005 19:20:37 -0400 Date: Thu, 16 Jun 2005 23:20:00 -0000 From: Bob Rossi To: Nick Roberts Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [PATCH] -stack-select-frame Message-ID: <20050616232037.GA23706@white> Mail-Followup-To: Nick Roberts , Daniel Jacobowitz , 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17074.566.194312.713028@farnswood.snap.net.nz> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-06/txt/msg00228.txt.bz2 On Fri, Jun 17, 2005 at 10:50:30AM +1200, Nick Roberts wrote: > > My concern was that this added a new item to a response which previous > > had zero. Why do you think people couldn't use it as is? Seems > > perfectly usable to me; if you know the level of a frame you want to > > select, then you probably already have the result of a backtrace which > > includes a printout of the stack frame, so you probably don't need > > another! > > -stack-select-frame without an argument currently works like the CLI command > "frame" without the output. All "frame" does is output the current frame, > so without output its a bit of a no-op. > > -stack-select-frame with an argument just works like up, down or more > precisely "frame FRAMENUM". So ,these CLI commands could be used directly in > the short term, and via "-interpreter-exec console" in the longer term, if the > frontend is not interested in the output. > > > Could you explain why you think we need output here? > > If you have a backtrace then, no, you don't need the output and the frontend > can ignore it. However, I presume "-stack-select-frame" runs more quickly > than "-stack-list-frames" so, if you don't need a backtrace, its probably best > not to require one. Yes, that sounds nice. Especially on an infinate recursion crash. The stack trace would take way to long to get back, so going frame by frame would be much nicer. Bob Rossi