From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14832 invoked by alias); 3 May 2005 20:49: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 13960 invoked from network); 3 May 2005 20:49:01 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 3 May 2005 20:49:01 -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 BDD25633 (AUTH halo1); Tue, 3 May 2005 23:48:47 +0300 (IDT) Date: Tue, 03 May 2005 20:49:00 -0000 From: "Eli Zaretskii" To: gdb-patches@sources.redhat.com Message-ID: <01c55021$Blat.v2.4$520aa7a0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050503194856.GA4477@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 3 May 2005 15:48:56 -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> <01c55017$Blat.v2.4$3cb51f20@zahav.net.il> <20050503194856.GA4477@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00091.txt.bz2 > Date: Tue, 3 May 2005 15:48:56 -0400 > From: Daniel Jacobowitz > Cc: gdb-patches@sources.redhat.com > > 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. Sorry, I joined the discussion in this thread only after you asked a question about the fullname regexp on non-Posix platforms. So _I_ am not going round. > This is where we disagree. GDB should do the search, yes. But it > should never ask the user to do any guessing again. I'm not sure we understand each other: who said anything about guessing or asking the user to do so? > 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. And where does this contradict anything that I said? For that matter, how is this at all related to the issue we are discussing, which I thought was how to test the output of the fullname attribute? > The path still has value in this case even if it doesn't exist! The same can be said about "\abc" or "d:foo". > We can't show the user the file, but we can use it to unambiguously > place a breakpoint in the correct file. The same can be said about "\abc" or "d:foo". > 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. Then let's do what I suggested: take the value of fullname and see if we can reach the file it names. There's no need for any regexp at all; moreover, even if we agree on some regexp, it is only a fuzzy test, since the fact that the output matches does not yet mean that the output is correct. > Secondly, if we get bogus information from the compiler we will try to > resolve it. Unfortunately, there's no specification known to me as to what can and cannot be recorded in the directory name of the source file in the debug info, at least not for Windows filesystems. I think I once saw a "../../foo/bar/baz.c" there, for example. So we cannot easily detect ``bogus'' here. > We should not be showing the raw data to a front end, only > the resolved path. I don't think this is a good idea, because we don't have enough information. If we try to resolve and the path winds up with incorrect value, the user will be unable to access the source file. OTOH, if we leave these semi-absolute file names intact, the user could remedy the situation by using the `cd' command from inside GDB.