From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6543 invoked by alias); 1 May 2005 02:19:59 -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 5952 invoked from network); 1 May 2005 02:19:47 -0000 Received: from unknown (HELO lakermmtao09.cox.net) (68.230.240.30) by sourceware.org with SMTP; 1 May 2005 02:19:47 -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 <20050501021945.DLDX6804.lakermmtao09.cox.net@white>; Sat, 30 Apr 2005 22:19:45 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DS43d-0005Cg-00; Sat, 30 Apr 2005 22:19:45 -0400 Date: Sun, 01 May 2005 02:19:00 -0000 From: Bob Rossi To: Dennis Brueni , gdb-patches@sources.redhat.com Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Message-ID: <20050501021945.GA19962@white> Mail-Followup-To: Dennis Brueni , gdb-patches@sources.redhat.com References: <20050430191755.GF7009@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050430191755.GF7009@nevyn.them.org> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-05/txt/msg00000.txt.bz2 On Sat, Apr 30, 2005 at 03:17:55PM -0400, Daniel Jacobowitz wrote: > On Fri, Apr 01, 2005 at 02:13:33PM -0500, Dennis Brueni wrote: > > > Again, for the fullname regex, I would recommend using the > > > same regex used in mi-file.exp. This would be like > > > fullname="/.*basics.c" This forces the regex to ensure that > > > the path is absolute, which the check you have does not. > > Will GDB always output absolute paths that start with "/"? What about > non-Cygwin Windows for example? DJGPP? Like Dennis noted, it could be possible that the fullname might not start with a "/". I originally posted the patch with the fullname starting with a "/", and since then, there hasn't been any complaints. If there is a better regex that ensures that the fullname is absolute I'd be happy to change the mi-file.exp test to it. > In any case, if you want to verify that fullname starts with a > full path, it can be an independent test. It doesn't need to live in > every other MI stack test. 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. Thanks, Bob Rossi