From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6498 invoked by alias); 4 May 2005 21:07:22 -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 5653 invoked from network); 4 May 2005 21:07:17 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 4 May 2005 21:07:17 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DTR5R-0000lu-5y; Wed, 04 May 2005 17:07:17 -0400 Date: Wed, 04 May 2005 21:07:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Message-ID: <20050504210717.GA2419@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb-patches@sources.redhat.com References: <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> <20050503194856.GA4477@nevyn.them.org> <01c55021$Blat.v2.4$520aa7a0@zahav.net.il> <20050504133437.GA10578@nevyn.them.org> <20050504183127.GA19094@nevyn.them.org> <01c550eb$Blat.v2.4$24b1dce0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c550eb$Blat.v2.4$24b1dce0@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00140.txt.bz2 On Wed, May 04, 2005 at 11:51:08PM +0300, Eli Zaretskii wrote: > > Date: Wed, 4 May 2005 14:31:28 -0400 > > From: Daniel Jacobowitz > > Cc: gdb-patches@sources.redhat.com > > > > If we're returning a fullname at all, we've decided where to open the > > file; we can share that decision with the user/client. > > That is perhaps true for openp, but not for xfullpath or gdb_realpath: > those functions don't open the file, they just manipulate the string > that is handed to them. I'm still just not following you. The value of those functions if they can not find the file is _nil_. You can't resolve symlinks in a directory path, for instance, if you can't find the directory. realpath() returns ENOENT if you hand it a path that does not exist. There are five calls to xfullpath in GDB. One is for debugging use (maint print msymbols). Two are interested in canonicalizing paths which already meet IS_ABSOLUTE_PATH, for the purposes of comparison. And the last two are in openp, after successfully opening the file. There are six calls to gdb_realpath. One is QNX-specific and I'm not precisely sure what it's for. Four are used on symtabs for string comparison. And the last one is in the implementation of xfullpath. > > The question is what a front end can expect from GDB. The > > documentation says it can expect an absolute path, not a > > semi-absolute path. > > If the front end is going to open the file, it doesn't matter. If it > is going to compare files for equality, it should not use string > comparison, for the reasons I explained in another message. If it's going to open files, it _does_ matter. You said that the current directory (and presumably the current drive) are global on this platform. But the current directory is not stable across time. If the front end changes the current directory after talking to GDB, suddenly it won't be able to open files. > Because it took me quite an effort to make GDB DTRT with MS-style file > names. So I don't want to see it go down the drain because of some > test case. The main reason for these functions is to handle files > which GDB needs to work with, not to display standardized names. That > is, the ultimate test is whether opening the file will work or not, > not if they look canonical. Canonicalization is a means, not an end > in itself, except in the test that started this. So I'm willing to > give up on this test, but not on what the code does, because I don't > want us to break much more important situations where the current code > works. Can you give me an example of when canonicalization would be harmful? The only one I can think of is "the current directory was wrong when we tried to open the file, so we change the current directory and things start working". This relies on a DJGPP specific property; if you want this behavior, the right way to do it is to make GDB re-resolve filenames when its current directory changes. -- Daniel Jacobowitz CodeSourcery, LLC