[RFC] Fix a bug in source file searching

[RFC] Fix a bug in source file searching

[Jie Zhang]

[-- Attachment #1: Type: text/plain, Size: 1987 bytes --]

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


[-- Attachment #2: gdb-fix-find-and-open-source.diff --]
[-- Type: text/x-patch, Size: 1071 bytes --]


	* source.c (find_and_open_source): Search file in compilation
	directory first.

Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.108
diff -u -p -r1.108 source.c
--- source.c	10 Mar 2010 18:20:06 -0000	1.108
+++ source.c	28 Mar 2010 15:54:07 -0000
@@ -971,6 +971,27 @@ find_and_open_source (const char *filena
 
   if (dirname != NULL)
     {
+      char *name, *rewritten_fullname;
+
+      name = concat (dirname, SLASH_STRING, filename, (char *)NULL);
+      rewritten_fullname = rewrite_source_path (name);
+
+      if (rewritten_fullname != NULL)
+	{
+	  *fullname = rewritten_fullname;
+	  xfree (name);
+	}
+      else
+	*fullname = name;
+      result = open (*fullname, OPEN_MODE);
+      if (result >= 0)
+	return result;
+      xfree (*fullname);
+      *fullname = NULL;
+    }
+
+  if (dirname != NULL)
+    {
       /* If necessary, rewrite the compilation directory name according
          to the source path substitution rules specified by the user.  */
 

Re: [RFC] Fix a bug in source file searching

[Tom Tromey]

>>>>> "Jie" == Jie Zhang <jie@codesourcery.com> writes:

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

Thanks.

Jie> And .gdbinit file in GCC build directory has
Jie>    dir ../../../svn/trunk/gcc/fortran
Jie> So it looked GDB searched pathes added by dir command first.

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

Maybe the documentation is just wrong or misleading here.  I say that
because the special entry `$cdir' expands to the compilation directory,
and you can control where this appears pretty easily.

Tom

Re: [RFC] Fix a bug in source file searching

[Jie Zhang]

On 03/31/2010 06:14 AM, Tom Tromey wrote:
>>>>>> "Jie" == Jie Zhang<jie@codesourcery.com>  writes:
>
> Jie>  I found this bug when debugging GCC. (Actually I don't know if this is
> Jie>  a bug in GDB code or documentation.) I prepared a patch so you can
> Jie>  easily comment.
>
> Thanks.
>
> Jie>  And .gdbinit file in GCC build directory has
> Jie>     dir ../../../svn/trunk/gcc/fortran
> Jie>  So it looked GDB searched pathes added by dir command first.
>
> Jie>  But the GDB documentation says in "9.5 Specifying Source Directories":
> Jie>  [quote]
> Jie>  For example, suppose an executable references the file
> Jie>  /usr/src/foo-1.0/lib/foo.c, and our source path is /mnt/cross. The
> Jie>  file is first looked up literally; if this fails,
> Jie>  /mnt/cross/usr/src/foo-1.0/lib/foo.c is tried; if this fails,
> Jie>  /mnt/cross/foo.c is opened; if this fails, an error message is
> Jie>  printed.
> Jie>  [/quote]
>
> Maybe the documentation is just wrong or misleading here.  I say that
> because the special entry `$cdir' expands to the compilation directory,
> and you can control where this appears pretty easily.
>
Maybe I misunderstood the document. I thought

comp_dir = /usr/src/foo-1.0
filename = lib/foo.c

should be same as

comp_dir =
filename = /usr/src/foo-1.0/lib/foo.c

Obviously GDB treats them differently although I don't know why.

And I don't know why GCC adds those dir commands in its .gdbinit. I will 
ask on GCC mailing list.

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

Re: [RFC] Fix a bug in source file searching

[Tom Tromey]

>>>>> "Jie" == Jie Zhang <jie@codesourcery.com> writes:

Tom> Maybe the documentation is just wrong or misleading here.  I say that
Tom> because the special entry `$cdir' expands to the compilation directory,
Tom> and you can control where this appears pretty easily.

Jie> Maybe I misunderstood the document. I thought
Jie> comp_dir = /usr/src/foo-1.0
Jie> filename = lib/foo.c
Jie> should be same as
Jie> comp_dir =
Jie> filename = /usr/src/foo-1.0/lib/foo.c

Jie> Obviously GDB treats them differently although I don't know why.

FWIW, I don't really understand the rationale behind why the code works
the way it does.

Further down in the info node it seems clear that it is intentional that
$cdir work this way, though.

If DWARF intends those two cases to be the same, then perhaps the fix
ought to be in dwarf2read.c.  I am not sure.

Jie> And I don't know why GCC adds those dir commands in its .gdbinit. I
Jie> will ask on GCC mailing list.

I think adding "dir $cdir" at the end of the list of dir commands would
also get the behavior you want.

Tom

Re: [RFC] Fix a bug in source file searching

[Jie Zhang]

On 04/08/2010 04:52 AM, Tom Tromey wrote:
>>>>>> "Jie" == Jie Zhang<jie@codesourcery.com>  writes:
> Jie>  And I don't know why GCC adds those dir commands in its .gdbinit. I
> Jie>  will ask on GCC mailing list.
>
> I think adding "dir $cdir" at the end of the list of dir commands would
> also get the behavior you want.
>
I have sent a patch to GCC:

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01468.html


Jie