[RFC] gdb_realpath causes problems with GVD

[Joel Brobecker]

> 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.

Right, and the GVD team is now aware of this issue. Let's now leave GVD
out of the picture, as it was the tool that uncovered the issue, but the
issue is actually independent from GVD.

> 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.

I think it is wrong to force the user to follow links (I'm trying to
find a not so strong way to voice my opinion, but not being a native
speaker I can't find any). There are some development systems where the
links are automagically, and the user sometimes does not know about
them.

Let me suggest the following: 
  - Use xfullpath when printing the filename in "info line"
  - Try both xfullpath and then  gdb_realpath when setting breakpoints.

That way, we remain consistent between the filenames known to the user,
the filenames displayed by GDB, but at the same time being lenient in
what we accept.

What do you think? Would that work for you?
-- 
Joel