From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19224 invoked by alias); 3 May 2005 19:49:07 -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 19127 invoked from network); 3 May 2005 19:48:57 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 3 May 2005 19:48:57 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DT3O4-0001GX-AA; Tue, 03 May 2005 15:48:56 -0400 Date: Tue, 03 May 2005 19:49: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: <20050503194856.GA4477@nevyn.them.org> 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.5.8i X-SW-Source: 2005-05/txt/msg00086.txt.bz2 On Tue, May 03, 2005 at 10:34:15PM +0300, Eli Zaretskii wrote: > > Date: Mon, 2 May 2005 23:46:05 -0400 > > From: Daniel Jacobowitz > > Cc: gdb-patches@sources.redhat.com > > > > > > That's not what we're testing for in the testsuite, though. > > > > > > What _are_ we trying to test? > > > > GDB is outputting an absolute path, which will be used by either the > > user or by a front end. In either case, it should locate the file > > entirely unambiguously. > > If that is what we want to test, then the test is IMHO inappropriate: > we shouldn't try to identify an absolute file name, we should see if > the name it produces corresponds to a real file. I.e., try to stat > the file, or maybe cmp it against the source whose path we know, or > something like that. Round and round we go... I believe I just argued the same point you're making here a little earlier, but gave in to Bob's wishes. These tests are not for the fullname feature. They merely include a fullname in their output. I'm all for putting fullname=".*basics.c" in them and leaving it at that. But if we're going to be more precise, then we should try to be completely precise; the regexp can be easily centralized. > > > > I think that we should reject both \abc and d:foo here. > > > > > > I don't think so. > > > > Could you explain why? > > Because (as I said in my other mail this morning) such semi-absolute > file names can be recorded in the debug info, albeit under somewhat > unusual circumstances. Since we don't own the compiler's code that > records file and directory names in the debug info, we can never be > 100% sure such file names will never end up there. When they do, > there's nothing we can do about them in GDB but try to find them, see > below. Failing the test because we see such file names will thus do a > misservice to us: it will mark a perfrctly legitimate result as a > failure. > > > 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? This is where we disagree. GDB should do the search, yes. But it should never ask the user to do any guessing again. GDB has to settle on a path eventually, whether or not that path ends up containing the file. I believe that GDB should settle on a path and report it precisely to the user. The path still has value in this case even if it doesn't exist! We can't show the user the file, but we can use it to unambiguously place a breakpoint in the correct file. Of course, if GDB is reduced to guessing, it may decide that two files who differ only in their current directory are the same. That's a limitation of the input debug information in some circumstances. First of all, in the testsuite we know the file will exist. If GDB can not find it, that's a bug. No matter what. It may be a bug in GDB or a bug in the compiler, but it is a bug, and I want the testsuite to detect it. If we don't, who will? We can't do simple things like "list" if we can't find the source files. Secondly, if we get bogus information from the compiler we will try to resolve it. We should not be showing the raw data to a front end, only the resolved path. I can see justification in reporting a non-absolute path to the user when GDB is absolutely stumped, but that's not this case. -- Daniel Jacobowitz CodeSourcery, LLC