Re: [RFC] gdb_realpath causes problems with GVD

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@ACT-Europe.FR> writes:

Joel> There is something in the break command that I haven't
Joel> understood, because:

Joel>       (gdb) b toto.C:5
Joel>       No source file named toto.C.
Joel>       (gdb) b /bonn.a/brobecke/toplevel/symlinks/toto.C:4
Joel>       Note: breakpoint 1 also set at pc 0x8048583.
Joel>       Breakpoint 2 at 0x8048583: file /bonn.a/brobecke/toplevel_link/symlinks/toto.c, line 4.

Joel> This seems odd to me that GDB refuses a breakpoint on toto.C,
Joel> but accepts a breakpoint on /bonn.a/.../toto.C?

If you give an absolute path to the break command, then gdb will try
to find and use the real path.

If you give a relative path to the break command, gdb won't do this.
It will just compare what you gave it to what is in the symtab.  It
might compare the base name if you didn't give an exact match.

See symtab.c:lookup_symtab() for the code.

Joel> I also noticed an inconsistency in the filename used in the
Joel> "Breakpoint 2 at ..." line, should this be also normalized?

I don't know.

Joel> Supposing that this problem can be corrected entirely in GVD,
Joel> should I withdraw my change request?

My opinion is that the primary bug here is in GVD.  However there are
subsidiary bugs as well.

Joel> I would still prefer GDB to display toto.c rather than toto.C as
Joel> the basename part, but I don't have a strong opinion so the
Joel> advice of all GDB developers would be welcome.

I agree it would be best if gdb could somehow tell GVD about the file
name as it appears in the symtab.  Then GVD could display this file
name if it so chose.

My reasoning here is that the file name in the symtab is most likely
the one the user will recognize, since it is the one that he (or the
Makefile or whatever) passed to the compiler.

Tom