From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18639 invoked by alias); 16 Jun 2005 13:21:56 -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 18166 invoked by uid 22791); 16 Jun 2005 13:21:23 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 16 Jun 2005 13:21:23 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DiuJ7-0001Q5-1l; Thu, 16 Jun 2005 09:21:21 -0400 Date: Thu, 16 Jun 2005 13:21:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] -stack-select-frame Message-ID: <20050616132120.GA5277@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17073.5179.249482.402135@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00218.txt.bz2 On Thu, Jun 16, 2005 at 05:55:07PM +1200, Nick Roberts wrote: > > - You're changing the behavior of a command; do people use this > > command? Are you confident that they will handle the new output > > gracefully? > > I'm not aware of anyone using this command - I don't see how they currently > could really. I think its less likely to break existing behaviour than this > change: > > 2005-05-17 Daniel Jacobowitz > Dennis Brueni > > * stack.c (print_frame): In MI mode, output a fullname attribute > with the stack frame. > > which must change the output for every frontend using MI. 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! Could you explain why you think we need output here? > I don't see how MI can evolve without changing its behaviour. If it is > significantly different presumably a new level can be added as before. That was my point: whether we needed to do that. I was just asking. > > > ! ^done,frame=@{level="2",addr="0x000107a4",func="foo", > > > ! file="recursive2.c",fullname="/home/foo/bar/devo/myproject/recursive2.c",line=line="14"@}, > > > > The double line= is a typo, right? > > I've just copied it from another part of the manual. In the node > "GDB/MI Command Description Format" it says: > > Manual> Note the the line breaks shown in the examples are here only for > Manual> readability. They don't appear in the real output. No, the bit that says "line=line="14"". -- Daniel Jacobowitz CodeSourcery, LLC