substitute-path problem

substitute-path problem

[Daniel Jacobowitz]

I was hoping substitute-path would come in handy today, but I couldn't
get it to work.  Here is the problem:

  if (dirname != NULL)
    {
      /* If necessary, rewrite the compilation directory name according
         to the source path substitution rules specified by the user.  */

      char *rewritten_dirname = rewrite_source_path (dirname);

But:

Breakpoint 3, find_and_open_source (objfile=0x8aa2f0,
    filename=0x9892d0 "/full/path/to/file.c", dirname=0x0,
    fullname=0x9892c0) at /space/fsf/commit/src/gdb/source.c:952

I suspect compiling the file with a full path on the gcc command line
would reproduce this.  Do you think we're applying the substitution
rule in the wrong place?

-- 
Daniel Jacobowitz
CodeSourcery

Re: substitute-path problem

[Joel Brobecker]

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

> I suspect compiling the file with a full path on the gcc command line
> would reproduce this.  Do you think we're applying the substitution
> rule in the wrong place?

I can indeed reproduce. I think that we are just missing one case.
First we try the fullpath if we already know it. Then the dirname
if we have it. But if there is no dirname, then we should try the
filename. Chances are, if the dirname is not specified, the file path
is embedded in the filename.

I will test the attach patch and commit if all is fine. In the meantim,
that might help you out in your work.

(I have wondered many times how much easier it would be for us if
we resolved the filename+dirname into a fullpath name at debug info
reading time, and then only stored that in our data structures - not
sure if it is posssible, but if it is, we would be able to assume in
the rest of the code that symbol->filename is always a fullpath, or
the closest to it we can do based on the information the compiler provided.
But I think that would change the behavior of certain things like source
file search with the dir path. I'm not completely sure yet, I would have
to spend some time researching this)

-- 
Joel

[-- Attachment #2: subst.diff --]
[-- Type: text/plain, Size: 753 bytes --]

Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.76
diff -u -p -r1.76 source.c
--- source.c	8 Aug 2006 22:06:06 -0000	1.76
+++ source.c	12 Jan 2007 03:15:55 -0000
@@ -1001,6 +1001,16 @@ find_and_open_source (struct objfile *ob
 	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
 	}
     }
+  else
+    {
+      char *rewritten_filename = rewrite_source_path (filename);
+
+      if (rewritten_filename != NULL)
+        {
+          make_cleanup (xfree, rewritten_filename);
+          filename = rewritten_filename;
+        }
+    }
 
   result = openp (path, OPF_SEARCH_IN_PATH, filename, OPEN_MODE, 0, fullname);
   if (result < 0)

Re: substitute-path problem

[Joel Brobecker]

> I will test the attach patch and commit if all is fine. In the meantim,
                                   ^^^^^^ SUBMIT!!!
> that might help you out in your work.

-- 
Joel

Re: substitute-path problem

[Daniel Jacobowitz]

On Fri, Jan 12, 2007 at 07:21:12AM +0400, Joel Brobecker wrote:
> (I have wondered many times how much easier it would be for us if
> we resolved the filename+dirname into a fullpath name at debug info
> reading time, and then only stored that in our data structures - not
> sure if it is posssible, but if it is, we would be able to assume in
> the rest of the code that symbol->filename is always a fullpath, or
> the closest to it we can do based on the information the compiler provided.
> But I think that would change the behavior of certain things like source
> file search with the dir path. I'm not completely sure yet, I would have
> to spend some time researching this)

Yes, this code is complicated and messy and really way too error prone;
the two cases should be the same.  This all ties in with the patch Jan
just posted (which I admit that I read, but could not make heads or
tails out of).  We need to make the two cases follow the same code path
or we'll keep breaking one of them.

It turns out find_and_open_source does plenty of other things wrong too
with dirname == NULL.  I saw it try to open "$cdir/scratch" (literally)
and also "/home/drow/scratch".  Not sure if that's really on purpose...
but the latter and a handy symlink solved my immediate problem :-)

BTW, if you have a chance to improve related things: help set
substitute-path was very unhelpful.  It doesn't say what the arguments
should be.

-- 
Daniel Jacobowitz
CodeSourcery

Re: substitute-path problem

[Joel Brobecker]

> It turns out find_and_open_source does plenty of other things wrong too
> with dirname == NULL.  I saw it try to open "$cdir/scratch" (literally)
> and also "/home/drow/scratch".  Not sure if that's really on purpose...
> but the latter and a handy symlink solved my immediate problem :-)

Neat :-). I wonder sometimes if it's possible to cover all cases.
There are so many (or perhaps my immediate short-term memory is not
what it should be).

> BTW, if you have a chance to improve related things: help set
> substitute-path was very unhelpful.  It doesn't say what the arguments
> should be.

Oh, I see you've tried that command too :-). I'll see if I can come
up with something. I need to refresh my memory about this, I hope
the documentation is a little better.

-- 
Joel