From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29330 invoked by alias); 3 May 2005 19:57:08 -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 29152 invoked from network); 3 May 2005 19:56:52 -0000 Received: from unknown (HELO lakermmtao08.cox.net) (68.230.240.31) by sourceware.org with SMTP; 3 May 2005 19:56:52 -0000 Received: from white ([68.9.64.121]) by lakermmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050503195651.PUML18139.lakermmtao08.cox.net@white>; Tue, 3 May 2005 15:56:51 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DT3Vi-0006gs-00; Tue, 03 May 2005 15:56:50 -0400 Date: Tue, 03 May 2005 19:57:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Message-ID: <20050503195650.GD25356@white> Mail-Followup-To: Eli Zaretskii , gdb-patches@sources.redhat.com References: <20050502005415.GA21588@white> <01c54f4d$Blat.v2.4$3ce76180@zahav.net.il> <20050502193638.GD22967@white> <01c54f50$Blat.v2.4$29b171c0@zahav.net.il> <20050502195515.GA10429@nevyn.them.org> <01c54f57$Blat.v2.4$4c163500@zahav.net.il> <20050502204859.GA6090@nevyn.them.org> <01c54f91$Blat.v2.4$f6e0b160@zahav.net.il> <20050503034604.GA437@nevyn.them.org> <01c55017$Blat.v2.4$3cb51f20@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c55017$Blat.v2.4$3cb51f20@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-05/txt/msg00088.txt.bz2 On Tue, May 03, 2005 at 10:34:15PM +0300, Eli Zaretskii wrote: > > Date: Mon, 2 May 2005 23:46:05 -0400 > > From: Daniel Jacobowitz > > Cc: gdb-patches@sources.redhat.com > > > > > > That's not what we're testing for in the testsuite, though. > > > > > > What _are_ we trying to test? > > > > GDB is outputting an absolute path, which will be used by either the > > user or by a front end. In either case, it should locate the file > > entirely unambiguously. > > If that is what we want to test, then the test is IMHO inappropriate: > we shouldn't try to identify an absolute file name, we should see if > the name it produces corresponds to a real file. I.e., try to stat > the file, or maybe cmp it against the source whose path we know, or > something like that. OK, I think I can solve some confusion here. At least, I feel that I just understood why you have your position to allow paths that are not absolute to be acceptable in the fullname output. When I originally added the field fullname, I purposely picked that name because I was unsure if the path would always be absolute. However, it was to my understand, that it would always be. Thus, in the manual I put, Synopsis -file-list-exec-source-file List the line number, the current source file, and the absolute path to the current source file for the current executable. I always expected the fullname to be absolute. This is why I made the original regex /.* > > > > I think that we should reject both \abc and d:foo here. > > > > > > I don't think so. > > > > Could you explain why? > > Because (as I said in my other mail this morning) such semi-absolute > file names can be recorded in the debug info, albeit under somewhat > unusual circumstances. Since we don't own the compiler's code that > records file and directory names in the debug info, we can never be > 100% sure such file names will never end up there. When they do, > there's nothing we can do about them in GDB but try to find them, see > below. Failing the test because we see such file names will thus do a > misservice to us: it will mark a perfrctly legitimate result as a > failure. Currently, any front end using the fullname output is expecting the output to be an absolute path to a file. If this is not the case in all circumstances, then the documentation and expections of the FE developers need's to change. I think it would be helpful if we could discover a case in which GDB would not be able to output an absolute path, but would still think that it has an absolute path. If that case is possible, than the doco needs to be updated and the fullname would consider absolute paths and some other special cases (\abc d:foo). If that case is not possible, then we can consider only absolute paths. Does this sound correct? The code to look at is source.c:openp. The filename_opened parameter is either - NULL - xfullpath (filename) where filename is potentially any file - xfullpath (current_directory/filename) Does anyone know what xfullpath would do if d:foo or \abc was passed to it? I look more into this... Thanks, Bob Rossi