From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16885 invoked by alias); 3 May 2005 22:50:29 -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 16715 invoked from network); 3 May 2005 22:50:19 -0000 Received: from unknown (HELO lakermmtao01.cox.net) (68.230.240.38) by sourceware.org with SMTP; 3 May 2005 22:50:19 -0000 Received: from white ([68.9.64.121]) by lakermmtao01.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050503225017.RXOQ11036.lakermmtao01.cox.net@white>; Tue, 3 May 2005 18:50:17 -0400 Received: from bob by white with local (Exim 3.35 #1 (Debian)) id 1DT6DU-0006or-00; Tue, 03 May 2005 18:50:12 -0400 Date: Tue, 03 May 2005 22:50:00 -0000 From: Bob Rossi To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Message-ID: <20050503225012.GA26132@white> Mail-Followup-To: Eli Zaretskii , gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c55017$Blat.v2.4$3cb51f20@zahav.net.il> User-Agent: Mutt/1.3.28i X-SW-Source: 2005-05/txt/msg00098.txt.bz2 > > What should the front end receiving this information do with it? > > It should do the best it can: try to access the file under the > assumption that the missing drive in "\abc" is the current one and the > missing directory in d:foo is the current directory on drive d: > (which could be different from the current drive). If that works, we > win; if not, tough. The failure case is the same situation as when > the front end receives a file name which does not exist on the machine > (e.g., a module from a library that was compiled on a different > computer): GDB tries its best to find the file, but if the directory > cannot be found by any algorithm known to us, we give up. What else > can we do? In the second case here, "when the front end receives a file name which does not exist on the machine ..." The comment for source.c:openp states that the FILENAME_OPENED output variable will always start with a "/". So, I'm assuming from what we've talked about, that this comment is wrong. I just realized that filename_opened is only populated if the variable "filename" was opened successfully by GDB. Then filename_opened is generated by doing xfullpath magic on the variable filename. The bad thing about that, is that GDB never attempts to open filename_opened to make sure that the file is there and is valid. Should openp attempt to open filename_opened to make sure that it is there? That would be one more step in the direction of making sure that the fullname is at least valid on the disk. That way, absolute or not, the front end will be able to rely on the fullname file being on the disk. Thanks, Bob Rossi