From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20257 invoked by alias); 3 May 2005 21:15: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 20017 invoked from network); 3 May 2005 21:15:12 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 3 May 2005 21:15:12 -0000 Received: from zaretski (IGLD-80-230-71-109.inter.net.il [80.230.71.109]) by legolas.inter.net.il (MOS 3.5.6-GR) with ESMTP id EHC54141 (AUTH halo1); Wed, 4 May 2005 00:15:09 +0300 (IDT) Date: Tue, 03 May 2005 21:15:00 -0000 From: "Eli Zaretskii" To: gdb-patches@sources.redhat.com Message-ID: <01c55025$Blat.v2.4$00e755e0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050503195650.GD25356@white> (message from Bob Rossi on Tue, 3 May 2005 15:56:50 -0400) Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Reply-to: Eli Zaretskii References: <20050502005415.GA21588@white> <01c54f4d$Blat.v2.4$3ce76180@zahav.net.il> <20050502193638.GD22967@white> <01c54f50$Blat.v2.4$29b171c0@zahav.net.il> <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> X-SW-Source: 2005-05/txt/msg00092.txt.bz2 > Date: Tue, 3 May 2005 15:56:50 -0400 > From: Bob Rossi > Cc: gdb-patches@sources.redhat.com > > When I originally added the field fullname, I purposely picked that name > because I was unsure if the path would always be absolute. However, it > was to my understand, that it would always be. Thus, in the manual I > put, > > Synopsis > -file-list-exec-source-file > > List the line number, the current source file, and the absolute path to > the current source file for the current executable. > > I always expected the fullname to be absolute. As I tried to explain, the Windows file names have a semi-absolute form. That form is generally treated like an absolute file name because the single most important cause for a program to test a file name for being absolute is to decide whether we need to prepend the cwd to it; d:foo and \abc certainly don't need that! The fullname field uses the machinery that was invented mainly for that purpose, so it inherits the same behavior. > Currently, any front end using the fullname output is expecting the > output to be an absolute path to a file. If this is not the case in all > circumstances, then the documentation and expections of the FE > developers need's to change. As I explained in my previous messages, there's nothing the FE can do but try accessing the file as if it were handed an absolute file name. So the FE doesn't need to worry about this and doesn't need to change its expectations in any way, because no change in expectations will ever succeed in resurrecting the missing information (the drive letter in the case of \abc and the current directory on drive d: in the case of d:foo). > I think it would be helpful if we could discover a case in > which GDB would not be able to output an absolute path, but would still > think that it has an absolute path. If that case is possible, than the > doco needs to be updated and the fullname would consider absolute paths > and some other special cases (\abc d:foo). If that case is not > possible, then we can consider only absolute paths. Does this sound > correct? I cannot say if this is correct because I cannot figure out what are you saying. What does it mean for fullname to consider absolute file names and also special cases like \abc? How will it ``consider'' them? > The code to look at is source.c:openp. The filename_opened parameter is > either > - NULL > - xfullpath (filename) where filename is potentially any file > - xfullpath (current_directory/filename) > > Does anyone know what xfullpath would do if d:foo or \abc was passed to > it? I already answered that in this thread: it will leave \abc intact, and d:foo will be converted into d:./foo. (On Windows, that is, and assuming that there's no realpath or canonicalize_file_name in MinGW.) So xfullpath does not change anything with these cases on Windows (and can't, since the necessary information is missing).