Hello,

The handing of relative paths in GDB has already been discussed (see
http://sourceware.org/ml/gdb-patches/2005-10/msg00039.html for the
latest thread). I don't believe there has been an agreement on a
solution.
I'd like to propose a little modification that makes things work for me
in the Dwarf2 case.
In fact, my starting point wasn't the general issue of relative paths,
but I saw GDB unable to find the include files of a program structured
like that:

 /project/
        include/
               header.h
        src/
           main.c  /* Includes header.h */
        main.o
        myprog

If GDB isn't launched from the root of the build tree, it is unable to
find header.h, whereas it can find main.c from anywhere. In the dwarf2
debug info, we get:

   DW_AT_name:          src/main.c
   DW_AT_comp_dir:      /project/
   files.files[0].name: header.h
   files.files[0].dir:  include/
   files.files[1].name: main.c
   files.files[1].dir:  src/

So if the build-tree stays at the same place, the debugger has all the
information available to be able to locate header.h, wherever the binary
really is and whatever $cwd is.

The main symtab will be built using DW_AT_name and DW_AT_comp_dir.
That's why GDB can find the main.c sourcefile without trouble. The
symtab for the header.h file is built using the line info dirname and
the line info filename. Which means it looses the comp_dir information.
I believe that the information in the line-tables related to a Dwarf2
compilation unit should be interpreted relatively to the compilation
unit comp_dir.

The attached patch implements something like that. When the line
information doesn't reference an absolute file, it uses comp_dir as the
subfile directory and concat(file.dir, "/", file.name) as filename.
If the build tree hasn't moved, then we've got all the information to
find the sources. If comp_dir doesn't exist anymore, then
find_and_open_source will basically do the same thing as with the old
information (it will split the basename if it can't find the full name).
I think that this also has the nice side-effect of making relative
include paths working with the 'dir' command as the full relative path
will get tested against each directory.
Note that the include psymtab building code a in dwarf_decode_lines does
a similar thing.
This seems also more consistent with find_and_open_source where $cdir
will get replaced by what we put in the symtab's dirname (implying that
we should always put the comp_dir in a symtab's dirname).

I've regression tested it on i686-pc-linux-gnu with gcc4.0. I wonder if
this could break things in some cases, maybe with other compilers than
GCC. Comments ?

Regards,
Fred.