Re: [RFC] gdb_realpath causes problems with GVD

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@ACT-Europe.FR> 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 "<some_path>/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