From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11664 invoked by alias); 5 May 2005 17:17:01 -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 11437 invoked from network); 5 May 2005 17:16:52 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 5 May 2005 17:16:52 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DTjxz-0004PT-GS for ; Thu, 05 May 2005 13:16:51 -0400 Date: Thu, 05 May 2005 17:17:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Message-ID: <20050505171650.GA16361@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <20050430191755.GF7009@nevyn.them.org> <20050501021945.GA19962@white> <20050505162233.GD31111@white> <20050505162543.GA14746@nevyn.them.org> <20050505164543.GA31758@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505164543.GA31758@white> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00169.txt.bz2 On Thu, May 05, 2005 at 12:45:43PM -0400, Bob Rossi wrote: > O, I see. I was going to add the regex and update mi-file.exp. However, > I noticed that mi2-file.exp also had a fullname field and realized I > didn't know if the mi2 files were going to be modified. Oh, those testcases. Go ahead. > I'm looking now, and just realized that Andrew didn't let me modify > mi2-file.exp to add -file-list-exec-source-files even though it was > compatible with the MI2 protocol. He only wanted me to add it to > mi-file.exp. So it looks like your initial idea was the philosophy > Andrew was taking, which is: MI2 is stable and it should not be modified. > I am going to take that approach with this patch. The one doesn't follow from the other. -file-list-exec-source-files shouldn't be tested as a part of MI2, because MI2 did not include it at its release. However, I don't see a problem with allowing extra fields, assuming that you are right about frontends being accepting of this. It isn't clearly spelled out in the manual, one way or another. > I really wish the MI release philosophy could be spelled out some where. > It seems as if Andrew considered MI versions to not be at the protocol > level. For instance, MI2 and MI3 could both use the same protocol, except > that MI3 would have more functions and fields than MI2. Does this sound > correct to you? This is part of the confusion I had when trying to figure > out how GDB would handle multiple MI protocols. I'm not the one you should be asking since I don't think all the multiple protocols work is/was useful. The model just has too many question marks in it when you consider all those busy beavers developing on the _rest_ of GDB. You're lucky if you get even one MI protocol to work. -- Daniel Jacobowitz CodeSourcery, LLC