From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15032 invoked by alias); 24 Mar 2002 05:35:12 -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 15025 invoked from network); 24 Mar 2002 05:35:10 -0000 Received: from unknown (HELO gash2.peakpeak.com) (207.174.178.17) by sources.redhat.com with SMTP; 24 Mar 2002 05:35:10 -0000 Received: from creche.cygnus.com (ta0194.peakpeak.com [204.144.244.194]) by gash2.peakpeak.com (8.9.3/8.9.3) with ESMTP id WAA17703; Sat, 23 Mar 2002 22:35:06 -0700 Received: (from tromey@localhost) by creche.cygnus.com (8.9.3/8.9.3) id XAA00314; Sat, 23 Mar 2002 23:08:38 -0700 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] gdb_realpath causes problems with GVD References: <20020319171236.D6465@act-europe.fr> <87adt2ri93.fsf@creche.redhat.com> <20020321091144.A30346@act-europe.fr> <20020321124411.A3351@act-europe.fr> From: Tom Tromey Reply-To: tromey@redhat.com X-Attribution: Tom X-Zippy: .. this must be what it's like to be a COLLEGE GRADUATE!! Date: Sat, 23 Mar 2002 21:35:00 -0000 In-Reply-To: Joel Brobecker's message of "Thu, 21 Mar 2002 12:44:11 +0100" Message-ID: <87663mo5uh.fsf@creche.redhat.com> X-Mailer: Gnus v5.7/Emacs 20.5 X-SW-Source: 2002-03/txt/msg00453.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> Based on a discussion I had with the GVD developers, I think Joel> that there is still some work needed to be done in GDB. When you Joel> start GVD on a program, GVD does an "info sources" to get the Joel> list of files, and then presents this list in a tree on which Joel> the user can click to view the file, put breakpoints, etc. Ok. Joel> This is means that most of the time, info sources will print a Joel> list of filenames with either relative path or no path at Joel> all. In order to locate a file, GVD needs to ask GDB. This is Joel> what it does using the "info line toto.c:1" command. Yes. The problem here is that gdb is giving an absolute path to GVD. GVD then sends just the basename back to gdb. This doesn't really make sense. I think GVD has two choices. First, it could use the path information as given by info sources. This is just the paths given in the symtab. Second, it could use the path information as printed by `b'. Instead, GVD is taking the basename of the path in question. That is a questionable operation. What if there are two files with the same base name? This is the scenario that lead to the patch in the first place. Unfortunately I think Insight also falls down here. I haven't looked into it recently though. Perhaps GVD is doing what it does in order to be compatible with older versions of gdb. I can sympathize with that. I suspect that using the full name as printed by `info sources' will work with any version of gdb, though I have not tested that theory. Another choice would be for GVD to use the gdb version number to decide whether it should send base- or full-names. BTW, I finally remembered the logic behind the apparent lookup_symtab() weirdness. Users want "b foo.c:57" to "just work". If there's only one foo.c in your program, this is unambiguous. In this situation we have to get the debugger to find foo.c for us. We can't use realpath information, because we don't have a base directory to start from. So we search through the info in the symtab to find the file. On the other hand, debugger UIs already know an absolute path to a file. If the program has multiple files with the same base name, you want your UI to always set a breakpoint (e.g., in response to a mouse click in the source window) in the correct file. This is where the realpath information comes in -- both gdb and the UI can find an absolute path to the file, but they might be different. If you just use the base name here then you wind up in a confusing, ambiguous situation; see my original posts for real examples. Joel> To which GDB answers "/toto.C". But then, GDB refuses Joel> to put a breakpoint on toto.C unless one uses the full path. GDB Joel> is inconsistent here, and I really believe this inconsistency Joel> needs to be fixed. You could modify lookup_symtab() to also check against the base name of the realpath. That would work, although it would add the possibility of more ambiguous choices. Anyway, as I've said earlier I think the primary problem here is in GVD. Joel> Either we modify GDB to be able to accept breakpoints on toto.C, Joel> or we make sure toto.c is not translated into toto.C. I think Joel> the shortest route is to avoid the toto.c -> toto.C translation. Suppose I'm editing this file in Emacs. Emacs, at least as I have it configured, likes to follow symlinks. So Emacs thinks the file is "/a/b/toto.C". In the symtab we have "toto.c". We compiled it in the directory "/c/d" using `gcc -c -g toto.c'. Now in Emacs I use C-x SPC to set a breakpoint in toto.C. Emacs (well, a hacked version that works with this feature) sends: b /a/b/toto.C:57 Currently gdb will search through the symtabs. It will see something `toto.c' and use realpath to turn it into /a/b/toto.C. And since this is equal to the argument to `b', the breakpoint will be set. With your proposed change, when we're searching through the symtabs we'll find `toto.c' and turn it into `/a/b/toto.c'. This isn't equal to the argument to `b', so gdb will give an error. At least, that's what I think. I haven't tried your patch. What do you think of this? Tom