From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22725 invoked by alias); 4 May 2005 20:30:04 -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 22546 invoked from network); 4 May 2005 20:29:59 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 4 May 2005 20:29:59 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DTQVL-0000IE-AR; Wed, 04 May 2005 16:29:59 -0400 Date: Wed, 04 May 2005 20:30: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: <20050504202959.GA781@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> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c550e6$Blat.v2.4$6d9c7f00@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00136.txt.bz2 On Wed, May 04, 2005 at 11:17:23PM +0300, Eli Zaretskii wrote: > > Date: Wed, 4 May 2005 09:45:38 -0400 > > From: Daniel Jacobowitz > > Cc: gdb-patches@sources.redhat.com > > > > > 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. > > > > Eli, this is inconsistent with the rest of the world. In the rest of > > the world, realpath() and canonicalize_file_name() call getcwd() (or > > the operating system's equivalent function). Can you explain to us why > > it is correct for other OSes to do this resolution in xfullpath (or > > wherever else), and for DJGPP not to? > > We are again talking past each other. What you describe is correct > for all platforms, including DJGPP and Windows, but not in the > specific circumstances which led us to this endless thread, which is > to find a fully qualified file name using the information recorded in > the debug info. 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. If we successfully find a file, openp will already call xfullpath, 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). 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. So, with that fix and on any system but DJGPP, the path returned in *FILENAME_OPENED will always be canonicalized via realpath, with the exception of the basename, as described in the comments around the call. So why shouldn't we do this same thing for DJGPP? If you'll tell me the appropriate DJGPP interfaces and test the result I'll even write the code myself; I can't do it from scratch since I have no hardware set up to deal with DJGPP. 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) could almost be replaced by an assertion that the path never looks like "d:foo". In fact it can't; that's because some callers of xfullpath may pass filenames that don't exist, so we may not get an absolute path back from realpath. -- Daniel Jacobowitz CodeSourcery, LLC