I found this bug when debugging GCC. (Actually I don't know if this is a 
bug in GDB code or documentation.) I prepared a patch so you can easily 
comment.

When I was trying to set a breakpoint on a function in GCC generated 
options.c, like cl_optimization_restore, GDB always thought it's the 
options.c in gcc/fortran/ . The related DWARF looks like:

      <4c5ddc>   DW_AT_name        : (indirect string, offset: 0x58826): 
options.c
      <4c5de0>   DW_AT_comp_dir    : (indirect string, offset: 0x5383): 
/home/jie/sources/gcc/builds/build.svn-trunk/gcc

and

   The File Name Table:
    Entry Dir     Time    Size    Name
    1     0       0       0       options.c

According to DWARF, Dir = 0 means the current directory of the 
compilation, which "is understood to be the zeroth entry and is not 
explicitly represented." So the full name of options.c should be 
"/home/jie/sources/gcc/builds/build.svn-trunk/gcc/options.c".

And .gdbinit file in GCC build directory has

    dir ../../../svn/trunk/gcc/fortran

So it looked GDB searched pathes added by dir command first.

But the GDB documentation says in "9.5 Specifying Source Directories":
[quote]
For example, suppose an executable references the file 
/usr/src/foo-1.0/lib/foo.c, and our source path is /mnt/cross. The file 
is first looked up literally; if this fails, 
/mnt/cross/usr/src/foo-1.0/lib/foo.c is tried; if this fails, 
/mnt/cross/foo.c is opened; if this fails, an error message is printed.
[/quote]

  From this words, it seems the current GDB behavior doesn't conforms to 
the documentation. This patch makes GDB first look up the file 
literally. Only one new FAIL found when doing regression testing on 
i686-pc-linux-gnu:

FAIL: gdb.reverse/i387-env-reverse.exp: record to end of main (timeout)

I think it's not an error caused by the patch.

Currently I have no reduced test case. If the idea is good, I can write 
up a test case.

Any comments?


-- 
Jie Zhang
CodeSourcery
(650) 331-3385 x735