From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3770 invoked by alias); 5 May 2005 16:22:48 -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 3733 invoked from network); 5 May 2005 16:22:35 -0000 Received: from unknown (HELO lakermmtao10.cox.net) (68.230.240.29) by sourceware.org with SMTP; 5 May 2005 16:22:35 -0000 Received: from white ([68.9.64.121]) by lakermmtao10.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050505162235.FIB7787.lakermmtao10.cox.net@white>; Thu, 5 May 2005 12:22:35 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DTj7R-0008F6-00; Thu, 05 May 2005 12:22:33 -0400 Date: Thu, 05 May 2005 16:22:00 -0000 From: Bob Rossi To: gdb-patches@sources.redhat.com Cc: Daniel Jacobowitz Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Message-ID: <20050505162233.GD31111@white> Mail-Followup-To: gdb-patches@sources.redhat.com, Daniel Jacobowitz References: <20050430191755.GF7009@nevyn.them.org> <20050501021945.GA19962@white> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050501021945.GA19962@white> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-05/txt/msg00164.txt.bz2 > Well, I do understand your point here but I'd prefer that all fullname > checks ensure that the path be absolute. The more I think about it, I > should probably make a variable called 'fullname_output' in the > testsuite that contains the regex output of a fullname. How does this > sound? > > > > As promised, here is an updated patch set with the regex > > > changes you suggested, plus checking for a little more directory > > > information with respect to the fullname path, to the extent > > > that we can be sure the test case still passes in all environments. > > > > I don't think adding fullname= to the -i=mi2 output is a good idea; MI2 > > is supposed to be stable. Bob, what do you think? Anyone else? > > As far as i understand, it is acceptable to add new fields to a stable > version of MI. It is the parsers responsibility to ignore MI fields that > they are unfamiliar with. I also understand that it is acceptable to add > new commands to an MI version. Making either of the 2 changes above does > not effect the version number of the MI release (AFAIK). > > With that said, I'm not quite sure what model Andrew had in mind > when releasing the MI versions. Here is 2 possibilities, > > Originally there is mi-. Once it becomes stable it is released as mi2-. > mi2- is never touched again, accept for bug fixes. All development and > new features is done on mi-. When mi- becomes stable again it is turned > into mi3-. > > Originally there is mi-. Once it becomes stable it is released as mi2-. > Any changes compatible with the MI2 protocol should be merged into the > mi- and mi2- testcases. Changes that are not compatible with mi2 should > be merged into mi-. When mi- becomes stable enough it could be moved > into mi3-. > > I prefer the second model. I think it is more flexible and would allow > for features to get into the MI protocol faster. Ping, any decision on this? I need to know if I should be modifing mi2 testcases or just mi? Thanks, Bob Rossi