Re: [RFC] gdb_realpath causes problems with GVD

[Joel Brobecker <brobecker@ACT-Europe.FR>]

> It would be useful if you could find such a counter example, because it
> would help me for future work in GDB to undertand if there was something
> I missed.

I think a counter example would definitely be helpful.

> Supposing that this problem can be corrected entirely in GVD, should I
> withdraw my change request? I would still prefer GDB to display toto.c
> rather than toto.C as the basename part, but I don't have a strong
> opinion so the advice of all GDB developers would be welcome.

Based on a discussion I had with the GVD developers, I think that
there is still some work needed to be done in GDB. When you start GVD on
a program, GVD does an "info sources" to get the list of files, and then
presents this list in a tree on which the user can click to view the
file, put breakpoints, etc.

The list looks like this:
<<
toto.c, ../wcsmbs/wchar.h, ../iconv/gconv.h, ../include/gconv.h, 
../sysdeps/unix/sysv/linux/i386/bits/wchar.h, 
>>

As you see, there is no path information regarding toto.c. In my
relatively modest experience, I find that the most common case of
compiler invocation is 

    "compiler <switches> <relative_path_or_no_path>/<filename>"

This is means that most of the time, info sources will print a list of
filenames with either relative path or no path at all. In order to
locate a file, GVD needs to ask GDB. This is what it does using
the "info line toto.c:1" command.

To which GDB answers "<some_path>/toto.C". But then, GDB refuses to put
a breakpoint on toto.C unless one uses the full path. GDB is
inconsistent here, and I really believe this inconsistency needs to be
fixed.

Either we modify GDB to be able to accept breakpoints on toto.C, or
we make sure toto.c is not translated into toto.C. I think the shortest
route is to avoid the toto.c -> toto.C translation.

Comments?
-- 
Joel