[RFC] gdb_realpath causes problems with GVD

[Joel Brobecker <brobecker at ACT-Europe dot FR>]

Machine: x86-inux

The problem appears when some of the files used to build the
application are symbolic links and when GDB annotations are activated.
For us, this happens when GVD, our graphical front-end, drives GDB.

First, the context: In Ada, the filename associated to a unit need to
follow a strict convention, and this convention is dictated by the
compiler. For instance, the GNAT convention says that the spec of
package Hello must be located in file hello.ads. But the Apex naming
schemes says that it must be named hello.1.ada. The trouble starts when
somebody wants to develop/navigate using Apex, while building and
debugging using GNAT. In order to solve this naming issue, it has been
decided to keep the Apex filenames, and to create one symbolic link per
file which name follows GNAT naming scheme. So far, so good.

Now, here is an example of this situation, where I replace Ada by C,
which shows the problem we encountered. Supose we have directory
called symlinks, in which we have one C file, called toto.C, and one
symbolic link to this file called toto.c:
<<
void
break_me (void)
{
}

int
main (void)
{
  break_me ();
}
>>

We build the executable using the symlink:

        % gcc -g -o toto toto.c

Let's debug toto to see what happens:
<<
GNU gdb 2002-03-19-cvs
[...]
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) set annotate 1
(gdb) b break_me
Breakpoint 1 at 0x804846b: file toto.c, line 4.
(gdb) run
Starting program: /bonn.a/brobecke/symlinks/toto 

Breakpoint 1, break_me () at toto.c:4
yy/bonn.a/brobecke/symlinks/toto.C:4:23:beg:0x804846b
                            ^^^^^^
>>

As you see, GDB has translated toto.c into toto.C. This translation
causes GDB to think that the inferior stopped in a file named toto.C
(which is not known to GDB, since the compiler used only toto.c). As a
consequence, when the user tries to put breakpoints using the GVD, GVD
issues the following break command

   (gdb) break toto.C:4

to which GDB answers
   
   No source file named toto.C

The translation is performed by gdb_realpath. I searched the gdb-patches
archives, and found the reason for this translation in a message from
Tom Tromey. I think I found a way to keep the fix to his problem and
then at the same time fix our issue: instead of canonicalizing the
entire filename, I suggest that we only expand the directory prefix
(ie the part returned by the "dirname" unix command).

Here is a patch which implements this idea. I'd like to get your opinion
on it. Ideally, I'll like to commit this change if it is ok. Here is the
change log:

2002-03-19  Joel Brobecker  <brobecker@gnat.com>

	* utils.c (gdb_canonicalize_path): New function.
	(gdb_realpath_fallback): New function.
	(gdb_realpath): Restrict the canonicalization to the directory
	prefix rather than canonicalizing the entire filename, to avoid
	returning a filename unknown to GDB when the file is actually a
	symbolic link.

This change was tested

BTW: I just a message requesting a change in the exact same function.
I haven't integrated it yet, because I don't know if it will be accepted
or not. If it is accepted, I can merge it and resubmit.

Thanks,
-- 
Joel

Attachment: difs
Description: utils.c.diff