From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4973 invoked by alias); 3 May 2005 19:36:53 -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 4891 invoked from network); 3 May 2005 19:36:40 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 3 May 2005 19:36:40 -0000 Received: from zaretski (IGLD-80-230-71-109.inter.net.il [80.230.71.109]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id BDC64921 (AUTH halo1); Tue, 3 May 2005 22:36:36 +0300 (IDT) Date: Tue, 03 May 2005 19:36:00 -0000 From: "Eli Zaretskii" To: gdb-patches@sources.redhat.com Message-ID: <01c55017$Blat.v2.4$3cb51f20@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050503034604.GA437@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 2 May 2005 23:46:05 -0400) Subject: Re: [RFC] fullname attribute for GDB/MI stack frames Reply-to: Eli Zaretskii References: <20050501021945.GA19962@white> <01c54e7a$Blat.v2.4$e31afae0@zahav.net.il> <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> X-SW-Source: 2005-05/txt/msg00085.txt.bz2 > 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. > > > 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?