From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32215 invoked by alias); 4 May 2005 21:24: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 32124 invoked from network); 4 May 2005 21:24:13 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 4 May 2005 21:24:13 -0000 Received: from zaretski (IGLD-80-230-9-69.inter.net.il [80.230.9.69]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id BDJ42174 (AUTH halo1); Thu, 5 May 2005 00:24:08 +0300 (IDT) Date: Wed, 04 May 2005 21:24:00 -0000 From: "Eli Zaretskii" To: gdb-patches@sources.redhat.com Message-ID: <01c550ef$Blat.v2.4$6d63f3c0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050504202959.GA781@nevyn.them.org> (message from Daniel Jacobowitz on Wed, 4 May 2005 16:29:59 -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> <20050503195650.GD25356@white> <01c55025$Blat.v2.4$00e755e0@zahav.net.il> <20050503213911.GB16440@trixie.casa.cgf.cx> <01c55061$Blat.v2.4$5a644e20@zahav.net.il> <20050504134538.GC10578@nevyn.them.org> <01c550e6$Blat.v2.4$6d9c7f00@zahav.net.il> <20050504202959.GA781@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00142.txt.bz2 > Date: Wed, 4 May 2005 16:29:59 -0400 > From: Daniel Jacobowitz > Cc: gdb-patches@sources.redhat.com > > This is where you have completely lost me. I need for you to explain > why it is OK for the "fully qualified file name" not to be an absolute > path on DJGPP. Because of 2 reasons: (1) there's nothing wrong with d:foo, so resolving the cwd on drive d: would mean gratuitous DOS-specific code in a general-purpose source file, which I try to avoid; and (2) because years I spent porting dozens of GNU packages to DJGPP led me to this engineering decision which I found to work well in _all_ of the many packages I ported. I'm not going to go back and recollect all of the complicated situations and reiterate hundreds of hours of testing and debugging, just so that openp and xfullpath will look logically perfect to an outsider. > If we successfully find a file, openp will already call xfullpath, Please let's not forget that xfullpath and gdb_realpath are also functions on their own. Not every file they deal with is going to be opened with openp. Thus, some transformations of the file names is not going to be positively validated by opening the resulting name. > after optionally prepending the current notion of current directory (in > the correct circumstances, i.e. !IS_ABSOLUTE_PATH, though I have begun > to think that that macro is seriously misnamed). See, that's exactly what I was afraid of: first, you want to make the regex right, then you question functions that worked for years since I fixed them, then you question IS_ABSOLUTE_PATH which works for I don't remember how much time in I don't remember how many ports I made... IS_ABSOLUTE_PATH says that d:foo is an absolute file name for a very good reason: that non-absolute file names are treated in a way that is blatantly incorrect on Windows (e.g., by prepending the cwd to them). If you want a better name, think of it as ISNT_NOT_ABSOLUTE_PATH, okay? > xfullpath calls gdb_realpath. At the moment that doesn't include the > MinGW32 bits to call resolve Windows paths to include the correct > drive/directory. That's simply an oversight; when this discussion is > over, I intend to fix it by using the implementation from libiberty, > which GCC already uses. Beware: you might break things by this change, since currently lrealpath returns file names with backslashes, which is not a good idea in a program that came from the Posix world. And even after that, there will be problems with UNCs and other subtleties. > With that change, the special case code in xfullpath to turn "d:foo" > into "d:.\foo" (which I do understand and see the justification for) d:./foo has the same issues you didn't like in d:foo: it still doesn't resolve the current directory. So I don't understand why it is better for you. The reason that d:foo is converted to d:./foo is that the rest of the code needs at least one slash in the file name. So we supply one. Adding a syscall to find the cwd on drive d: would be an unjustified complication: another syscall, the need to deal with errors, etc.