From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17409 invoked by alias); 4 May 2005 14:52:14 -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 16840 invoked from network); 4 May 2005 14:52:00 -0000 Received: from unknown (HELO cgf.cx) (66.30.17.189) by sourceware.org with SMTP; 4 May 2005 14:52:00 -0000 Received: by cgf.cx (Postfix, from userid 201) id 7C83713C7E2; Wed, 4 May 2005 10:52:00 -0400 (EDT) Date: Wed, 04 May 2005 14:52:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com, Eli Zaretskii Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Message-ID: <20050504145200.GI24661@trixie.casa.cgf.cx> Mail-Followup-To: gdb-patches@sources.redhat.com, Eli Zaretskii References: <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> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c55061$Blat.v2.4$5a644e20@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00116.txt.bz2 On Wed, May 04, 2005 at 07:24:47AM +0300, Eli Zaretskii wrote: >> Date: Tue, 3 May 2005 17:39:11 -0400 >> From: Christopher Faylor >> >> Cygwin has realpath and Windows has an equivalent function. AFAIK, it >> will correctly translate \abc to x:\abc. > >No, it will _incorrectly_ translate them: the current drive and >directory that are in effect when we call these functions are _not_ >what they were when the compiler compiled the source and recorded its >file name in the debug info. > >> I don't know what it will do with d:foo. NT+ shells treat that as >> "the current directory on drive d:" but that's just something that >> is special to a shell. > >Not true: the notion of a current directory on drive d: is maintained >by the OS. The current directory on another drive is maintained by the "OS" only on Windows 9x variants and on MS-DOS. Otherwise the current directory is stored in hidden environment variables by the shell. XP/NT and 9x differ in this regard. >There's a special OS data structure where it holds the current >directory for each drive. Also, unlike on Unix, the current directory >on each drive is globally in effect for all the processes that run in >the current VM. This is true only on 9x/Me (and MS-DOS). >> Probably it should be resolved as "d:\foo". > >Please! I'm gonna cry! you are suggesting to revert the code that took >hard work to get right! openp used to do d:foo -> d:/foo, but that >was blatantly wrong and caused bugs. Let's not go that way just >because some test case doesn't seem 100% right! > >I am frustrated by my evident inability to communicate to you all the >simple truth: openp IS OKAY, IT DOESN'T NEED ANY FIXING! I just built a simple test case (tm) using a mingw version of lrealpath from libiberty. It fully canonicalizes the path and it even works on XP, so, apparently, GetFullPathName understand the hidden environment variables. So, if I type: myrealpath d:foo and the cwd on d: is set to \tmp: c:\>./myrealpath d:foo d:\tmp\foo c:\>env - ./myrealpath d:foo d:\foo So, AFAICT, libiberty is working fine and it should be safe to expect that canonicalized names on windows will either be in the form of x:\y\z or \\x\y\z if this is used. >> Hopefully the Windows >> routine for producing absolute paths will do something sensical. > >They won't; see above. > >> Anyway, it seems like the mingw port should be using GetFullPathName() >> in gdb_realpath(). > >I don't see this in my sandbox. I don't see any calls to lrealpath in gdb either. So, it seems like gdb isn't using this functionality but maybe it should be. cgf