From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22029 invoked by alias); 4 May 2005 21:42:55 -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 21545 invoked from network); 4 May 2005 21:42:48 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 4 May 2005 21:42:48 -0000 Received: from zaretski (IGLD-80-230-9-69.inter.net.il [80.230.9.69]) by legolas.inter.net.il (MOS 3.5.6-GR) with ESMTP id EHI37601 (AUTH halo1); Thu, 5 May 2005 00:42:46 +0300 (IDT) Date: Wed, 04 May 2005 21:42:00 -0000 From: "Eli Zaretskii" To: gdb-patches@sources.redhat.com Message-ID: <01c550f2$Blat.v2.4$07cfe520@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050504210717.GA2419@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 4 May 2005 17:07:17 -0400) Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Reply-to: Eli Zaretskii 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> <20050504210717.GA2419@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00143.txt.bz2 > Date: Wed, 4 May 2005 17:07:17 -0400 > From: Daniel Jacobowitz > Cc: gdb-patches@sources.redhat.com > > The value of those functions if they can not find the file is _nil_. No, it's not. Given enough information, e.g., the leading directories and the basename, one can reconstruct the absolute file name even if it no longer exists. > realpath() returns ENOENT if you hand it a path that does not exist. Does GetFullPathName on Windows fails in similar ways for non-existent files? In any case, the fact that realpath fails for non-existent files does not seem to be documented, and I, for one, would not necessarily expect that, as some similar functions and system calls I've met over the years on other platforms didn't fail like that. > 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. I don't follow the rationale for enumerating the current uses. These are sufficiently general-purpose functions; even if today they are used in certain contexts, tomorrow someone could use them in a different context. We need to think about potential uses even if they aren't currently in the sources. > > 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. In some (hopefully rare) cases, yes. \abc will remain correct as long as you don't change the drive; d:foo and d:./foo will remain correct as long as you don't change the cwd on drive d:. Both changes are rare in practice. However, similar changes that invalidate file names can happen on Unix as well: mounted file systems can be unmounted, symlinks can be broken, etc. When that happens, GDB will no longer be able to open the file, even if its name is 100% absolute. > Can you give me an example of when canonicalization would be harmful? It's gratuitous, even if the result is correct. And we don't know how to detect when it is correct. > 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 ??? What DJGPP specific property? What I had in mind was the GDB "cd" command typed by the user (who presumably knows where to go), not something specific to DJGPP.