Relative source file search

Relative source file search

[Craig Jeffree]

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

A while ago I reported problems locating source files that are specified
with relative paths in the compile line, detailed here:

http://sourceware.org/ml/gdb/2005-08/msg00066.html

Since then I've had a play around with the code and come up with the
attached diff which seems to solve the problem for me.  I couldn't see
any side effects as a result.

Can someone run a second set of eyes over this so that it can get
accepted to the mainline.

Thanks,
Craig.


[-- Attachment #2: relsrcsrch.diff --]
[-- Type: text/x-patch, Size: 1657 bytes --]

Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.70
diff -c -p -r1.70 source.c
*** source.c	29 Aug 2005 12:57:49 -0000	1.70
--- source.c	27 Sep 2005 07:27:26 -0000
*************** find_and_open_source (struct objfile *ob
*** 893,901 ****
--- 893,917 ----
  int
  open_source_file (struct symtab *s)
  {
+   char *filename;
+ 
    if (!s)
      return -1;
  
+   /* Use the concatenation of dirname and filename if dirname isn't absolute */
+   if (s->filename && s->dirname && !IS_ABSOLUTE_PATH (s->dirname))
+   {
+     filename = (char *) 
+       alloca (strlen (s->dirname) + strlen (SLASH_STRING) + 
+               strlen (s->filename) + 1);
+ 
+     strcpy(filename, s->dirname);
+     strcat(filename, SLASH_STRING);
+     strcat(filename, s->filename);
+           
+     return find_and_open_source (s->objfile, filename, NULL, &s->fullname);
+   }      
+ 
    return find_and_open_source (s->objfile, s->filename, s->dirname, 
  			       &s->fullname);
  }
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.7365
diff -c -p -r1.7365 ChangeLog
*** ChangeLog	26 Sep 2005 22:31:16 -0000	1.7365
--- ChangeLog	27 Sep 2005 07:27:31 -0000
***************
*** 1,3 ****
--- 1,8 ----
+ 2005-09-27  Craig Jeffree <craig.jeffree@preston.net>
+ 
+ 	* source.c (open_source_file): Handle relative dirname during source
+         file search.
+ 
  2005-09-26  Nick Roberts  <nickrob@snap.net.nz>
  
  	* Makefile.in (HFILES_NO_SRCDIR): Remove minimon.h, symfile-mem.h.

Re: [PATCH] Relative source file search

[Craig Jeffree]

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

Hi all,

What needs to occur for a patch like this to be accepted?  Is anyone
able to look at it and possibly commit it?

Cheers,
Craig.

On Tue, 2005-09-27 at 17:39 +1000, Craig Jeffree wrote:
> A while ago I reported problems locating source files that are specified
> with relative paths in the compile line, detailed here:
> 
> http://sourceware.org/ml/gdb/2005-08/msg00066.html
> 
> Since then I've had a play around with the code and come up with the
> attached diff which seems to solve the problem for me.  I couldn't see
> any side effects as a result.
> 
> Can someone run a second set of eyes over this so that it can get
> accepted to the mainline.
> 
> Thanks,
> Craig.
> 

[-- Attachment #2: relsrcsrch.diff --]
[-- Type: text/x-patch, Size: 1657 bytes --]

Index: source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.70
diff -c -p -r1.70 source.c
*** source.c	29 Aug 2005 12:57:49 -0000	1.70
--- source.c	27 Sep 2005 07:27:26 -0000
*************** find_and_open_source (struct objfile *ob
*** 893,901 ****
--- 893,917 ----
  int
  open_source_file (struct symtab *s)
  {
+   char *filename;
+ 
    if (!s)
      return -1;
  
+   /* Use the concatenation of dirname and filename if dirname isn't absolute */
+   if (s->filename && s->dirname && !IS_ABSOLUTE_PATH (s->dirname))
+   {
+     filename = (char *) 
+       alloca (strlen (s->dirname) + strlen (SLASH_STRING) + 
+               strlen (s->filename) + 1);
+ 
+     strcpy(filename, s->dirname);
+     strcat(filename, SLASH_STRING);
+     strcat(filename, s->filename);
+           
+     return find_and_open_source (s->objfile, filename, NULL, &s->fullname);
+   }      
+ 
    return find_and_open_source (s->objfile, s->filename, s->dirname, 
  			       &s->fullname);
  }
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.7365
diff -c -p -r1.7365 ChangeLog
*** ChangeLog	26 Sep 2005 22:31:16 -0000	1.7365
--- ChangeLog	27 Sep 2005 07:27:31 -0000
***************
*** 1,3 ****
--- 1,8 ----
+ 2005-09-27  Craig Jeffree <craig.jeffree@preston.net>
+ 
+ 	* source.c (open_source_file): Handle relative dirname during source
+         file search.
+ 
  2005-09-26  Nick Roberts  <nickrob@snap.net.nz>
  
  	* Makefile.in (HFILES_NO_SRCDIR): Remove minimon.h, symfile-mem.h.

Re: [PATCH] Relative source file search

[Daniel Jacobowitz]

On Tue, Oct 04, 2005 at 11:23:59AM +1000, Craig Jeffree wrote:
> Hi all,
> 
> What needs to occur for a patch like this to be accepted?  Is anyone
> able to look at it and possibly commit it?

I took a brief look at it, and felt that it was in the wrong place,
i.e. belonged in openp.  I haven't had a chance to come back to it yet.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Relative source file search

[Craig Jeffree]

On Mon, 2005-10-03 at 21:35 -0400, Daniel Jacobowitz wrote:
> I took a brief look at it, and felt that it was in the wrong place,
> i.e. belonged in openp.  I haven't had a chance to come back to it yet.
> 

I considered this, however the information provided by the symtab
doesn't fit with this.  In the case that I'm experiencing I start up GDB
with a binary and issue this dir command:

dir /staff/taam/taam/bin/x86-Linux/nostrip/

which is the directory where the application was built.

When I do a "list GeAttribute.H:1" and break GDB at the start of
open_source_file() I get the following information in the symtab:

s->filename = "GeAttribute.H"
s->dirname = "../../../include/General"
s->fullname = 0x0

This dirname/filename concatenation is correct if taken relative to the
binary location added to the directory search path.

So open_source_file() calls find_and_open_source() which replaces
"$cdir" in the source search path with the value from s->dirname.
However this means the file cannot be found because openp() then
searches for the filename in each of the directories in the source
search path but this path now contains a relative path that depends on
one of the other entries in the path.

I don't think it makes sense for openp to start fiddling around with
combinations of directories from the path, however I can understand
wanting to move this into find_and_open_source() since open_source_file
() is meant to be a convenience function.

Would a move to find_and_open_source() instead of openp() be acceptable?

Cheers,
Craig.

Re: [PATCH] Relative source file search

[Bob Rossi]

On Thu, Oct 06, 2005 at 10:57:10AM +1000, Craig Jeffree wrote:
> On Mon, 2005-10-03 at 21:35 -0400, Daniel Jacobowitz wrote:
> > I took a brief look at it, and felt that it was in the wrong place,
> > i.e. belonged in openp.  I haven't had a chance to come back to it yet.
> > 
> 
> I considered this, however the information provided by the symtab
> doesn't fit with this.  In the case that I'm experiencing I start up GDB
> with a binary and issue this dir command:
> 
> dir /staff/taam/taam/bin/x86-Linux/nostrip/
> 
> which is the directory where the application was built.
> 
> When I do a "list GeAttribute.H:1" and break GDB at the start of
> open_source_file() I get the following information in the symtab:
> 
> s->filename = "GeAttribute.H"
> s->dirname = "../../../include/General"
> s->fullname = 0x0
> 
> This dirname/filename concatenation is correct if taken relative to the
> binary location added to the directory search path.
> 
> So open_source_file() calls find_and_open_source() which replaces
> "$cdir" in the source search path with the value from s->dirname.
> However this means the file cannot be found because openp() then
> searches for the filename in each of the directories in the source
> search path but this path now contains a relative path that depends on
> one of the other entries in the path.
> 
> I don't think it makes sense for openp to start fiddling around with
> combinations of directories from the path, however I can understand
> wanting to move this into find_and_open_source() since open_source_file
> () is meant to be a convenience function.
> 
> Would a move to find_and_open_source() instead of openp() be acceptable?

Hi Craig,

I've been thinking about this a little. Here's the documentation for
explaining how the 'dir' command works.

  Plain file names, relative file names with leading directories, file names 
  containing dots, etc. are all treated as described above; for instance, 
  if the source path is `/mnt/cross', and the source file is recorded as 
     `../lib/foo.c', GDB would first try `../lib/foo.c', then 
     `/mnt/cross/../lib/foo.c', and after that---`/mnt/cross/foo.c'. 

This documentation describes the steps taken in order to find a file. It
doesn't describe using the symtabs dirname field. As I look at the code
in source.c:find_and_open_source I find that if dirname is not NULL,
then source_path get's set to "dirname:$cwd", and if the user used the
'dir' command to add directory's you end up with
"/home/dir1:/home/dir2:dirname:$cwd".

So, if your dirname is relative, like "../include", and your filename is
"foo.h", then moving your executable should not be a problem. I think
the problem is where you start GDB from. I find that if I start GDB
from where the executable original was, then it finds the file no
problem. If you start GDB from somewhere else, then the relative path
makes no sense to GDB.

Can you try starting GDB from the correct location and see if this fixes
your problem?

Thanks,
Bob Rossi

Re: [PATCH] Relative source file search

[Craig Jeffree]

On Wed, 2005-10-05 at 22:15 -0400, Bob Rossi wrote:
> I've been thinking about this a little. Here's the documentation for
> explaining how the 'dir' command works.
> 
>   Plain file names, relative file names with leading directories, file names 
>   containing dots, etc. are all treated as described above; for instance, 
>   if the source path is `/mnt/cross', and the source file is recorded as 
>      `../lib/foo.c', GDB would first try `../lib/foo.c', then 
>      `/mnt/cross/../lib/foo.c', and after that---`/mnt/cross/foo.c'. 
> 

I think my change works in support of this, but there is some
complication that I don't understand.  In one example that I've got
dirname is relative and filename is just the filename.  However in
another example dirname is empty and filename is a relative path like
the ../lib/foo.c example from the docs.  This later case works fine all
the time (haven't looked at the final test of /mnt/cross/foo.c though),
however the first case fails.  My change converts this first case into
the second case.  What I don't understand is why does the symtab
sometimes have the path and filename separate and other times have them
already concatenated?

> This documentation describes the steps taken in order to find a file. It
> doesn't describe using the symtabs dirname field. As I look at the code
> in source.c:find_and_open_source I find that if dirname is not NULL,
> then source_path get's set to "dirname:$cwd", and if the user used the
> 'dir' command to add directory's you end up with
> "/home/dir1:/home/dir2:dirname:$cwd".
> 
> So, if your dirname is relative, like "../include", and your filename is
> "foo.h", then moving your executable should not be a problem. I think
> the problem is where you start GDB from. I find that if I start GDB
> from where the executable original was, then it finds the file no
> problem. If you start GDB from somewhere else, then the relative path
> makes no sense to GDB.
> 
> Can you try starting GDB from the correct location and see if this fixes
> your problem?

Yes this does work, but its quite restrictive.  We're now letting GDB
dictate what your current working directory is allowed to be.  Our
application's behaviour depends on the cwd and so I can't always run it
from where GDB would feel more comfortable.  I believe the dir command
exists for this very reason, so I can explain to GDB where it will find
the source.

Cheers,
Craig.

Re: [PATCH] Relative source file search

[Bob Rossi]

On Thu, Oct 06, 2005 at 12:48:37PM +1000, Craig Jeffree wrote:
> On Wed, 2005-10-05 at 22:15 -0400, Bob Rossi wrote:
> > I've been thinking about this a little. Here's the documentation for
> > explaining how the 'dir' command works.
> > 
> >   Plain file names, relative file names with leading directories, file names 
> >   containing dots, etc. are all treated as described above; for instance, 
> >   if the source path is `/mnt/cross', and the source file is recorded as 
> >      `../lib/foo.c', GDB would first try `../lib/foo.c', then 
> >      `/mnt/cross/../lib/foo.c', and after that---`/mnt/cross/foo.c'. 
> > 
> 
> I think my change works in support of this, but there is some
> complication that I don't understand.  In one example that I've got
> dirname is relative and filename is just the filename.  However in
> another example dirname is empty and filename is a relative path like
> the ../lib/foo.c example from the docs.  This later case works fine all
> the time (haven't looked at the final test of /mnt/cross/foo.c though),
> however the first case fails.  My change converts this first case into
> the second case.  What I don't understand is why does the symtab
> sometimes have the path and filename separate and other times have them
> already concatenated?

Yes, this makes sense. Basically, the dirname is simply added to the
source path, nothing else is done with it. AFAIK, the symtab will have
the filename be what you gave to it on the compile line. For example,
'gcc -g ../main.c -o main' will give a filename of '../main.c', and if
you do 'gcc -g main.c -o main', it will give a filename of 'main.c'.
However, I'm not an expert on this.

So I think GDB is doing what it says it should do in the documentation.
Basically, if you have a filename of '../lib/foo.c', GDB tries that
first. Then for each source path it does 'source_path[i]/../lib/foo.c'.
Finally, for some strange reason it does 'source_path[i]/foo.c'. All of
this has nothing to do with the dirname, except for the fact that the
dirname get's put into the source path.

If you have includes like '../lib/foo.c' which are relative to where the
executable was, then when you run the 'dir exe_location', then GDB will
be able to find the file. However, if you have non-relative paths like
foo.c, then GDB will not be able to find it.

> > Can you try starting GDB from the correct location and see if this fixes
> > your problem?
> 
> Yes this does work, but its quite restrictive.  We're now letting GDB
> dictate what your current working directory is allowed to be.  Our
> application's behaviour depends on the cwd and so I can't always run it
> from where GDB would feel more comfortable.  I believe the dir command
> exists for this very reason, so I can explain to GDB where it will find
> the source.

Yes, you are correct. It would be nice to have GDB start from anywhere,
and allow it to find your files. I think we are going to have to make a
change to GDB, which alters the way it looks for files. For instance, if
you want to start using the dirname, do we make those checks before the
others, or after? Here's the current order looking for foo.c with
dirname of '../src'

   1. Look for foo.c
   2. For each source_path, Look for source_path[i]/foo.c

   This case will search for 'foo.c' and '../src/foo.c'.

The new search would be something like,
   
   1. Look for foo.c
   2. For each source_path, Look for source_path[i]/foo.c
   3. Look for ../src/foo.c /* Not needed */
   4. For each source_path, Look for source_path[i]/../src/foo.c

   This case will search for 'foo.c', '../src/foo.c', '../src/foo.c'
   and source_path[i]/../src/foo.c. The 3 case isn't needed, since it
   will be searched for in the second case.

Is this what you are suggesting to change?

Thanks,
Bob Rossi

Re: [PATCH] Relative source file search

[Craig Jeffree]

On Thu, 2005-10-06 at 09:00 -0400, Bob Rossi wrote:
> Yes, this makes sense. Basically, the dirname is simply added to the
> source path, nothing else is done with it. AFAIK, the symtab will have
> the filename be what you gave to it on the compile line. For example,
> 'gcc -g ../main.c -o main' will give a filename of '../main.c', and if
> you do 'gcc -g main.c -o main', it will give a filename of 'main.c'.
> However, I'm not an expert on this.

I wonder how this works with header files, in my application for some
reason the filename ends up being split into dirname (the relative path
bit) and filename (just the actual filename).  However in a little test
case I tried to make to reproduce it I ended up with an empty dirname
and the whole relative path+filename in filename.  It's only the former
case that causes problems.

> Here's the current order looking for foo.c with
> dirname of '../src'
> 
>    1. Look for foo.c
>    2. For each source_path, Look for source_path[i]/foo.c
> 
>    This case will search for 'foo.c' and '../src/foo.c'.
> 
> The new search would be something like,
>    
>    1. Look for foo.c
>    2. For each source_path, Look for source_path[i]/foo.c
>    3. Look for ../src/foo.c /* Not needed */
>    4. For each source_path, Look for source_path[i]/../src/foo.c
> 
>    This case will search for 'foo.c', '../src/foo.c', '../src/foo.c'
>    and source_path[i]/../src/foo.c. The 3 case isn't needed, since it
>    will be searched for in the second case.
> 
> Is this what you are suggesting to change?

Not quite.  I'm proposing "If dirname is absolute behave as it does now,
if dirname is relative prepend it to filename and treat dirname as
empty".  This gives the new search from your example above to be...

   1.  Look for ../src/foo.c
   2.  For each source_path, Look for source_path[i]/../src/foo.c

I believe this is how it already behaves in all cases where the symtab
contains an empty dirname and a relatively pathed filename.  Ideally we
should have consitent behaviour for the case where the relative path bit
is in dirname.

Cheers,
Craig.

Re: [PATCH] Relative source file search

[Bob Rossi]

On Fri, Oct 07, 2005 at 09:32:00AM +1000, Craig Jeffree wrote:
> On Thu, 2005-10-06 at 09:00 -0400, Bob Rossi wrote:
> > Yes, this makes sense. Basically, the dirname is simply added to the
> > source path, nothing else is done with it. AFAIK, the symtab will have
> > the filename be what you gave to it on the compile line. For example,
> > 'gcc -g ../main.c -o main' will give a filename of '../main.c', and if
> > you do 'gcc -g main.c -o main', it will give a filename of 'main.c'.
> > However, I'm not an expert on this.
> 
> I wonder how this works with header files, in my application for some
> reason the filename ends up being split into dirname (the relative path
> bit) and filename (just the actual filename).  However in a little test
> case I tried to make to reproduce it I ended up with an empty dirname
> and the whole relative path+filename in filename.  It's only the former
> case that causes problems.

Yes, I reproduced the problem with the former. If you have this
directory structure:
   gdb_path/
     src/
       main.c
     include/
       foo.h
and you compile in src/ with 'gcc -g main.cpp -I../include -o main' then
you will end up with dirname=../include and filename=foo.h.

> > Here's the current order looking for foo.c with
> > dirname of '../src'
> > 
> >    1. Look for foo.c
> >    2. For each source_path, Look for source_path[i]/foo.c
> > 
> >    This case will search for 'foo.c' and '../src/foo.c'.
> > 
> > The new search would be something like,
> >    
> >    1. Look for foo.c
> >    2. For each source_path, Look for source_path[i]/foo.c
> >    3. Look for ../src/foo.c /* Not needed */
> >    4. For each source_path, Look for source_path[i]/../src/foo.c
> > 
> >    This case will search for 'foo.c', '../src/foo.c', '../src/foo.c'
> >    and source_path[i]/../src/foo.c. The 3 case isn't needed, since it
> >    will be searched for in the second case.
> > 
> > Is this what you are suggesting to change?
> 
> Not quite.  I'm proposing "If dirname is absolute behave as it does now,
> if dirname is relative prepend it to filename and treat dirname as
> empty".  This gives the new search from your example above to be...
> 
>    1.  Look for ../src/foo.c
>    2.  For each source_path, Look for source_path[i]/../src/foo.c
> 
> I believe this is how it already behaves in all cases where the symtab
> contains an empty dirname and a relatively pathed filename.  

Yes, it probably does behave that way.

> Ideally we should have consistent behavior for the case where the relative path bit
> is in dirname.

Does anyone have any ideas why doing this would cause GDB to not find
files it does now? Craig, you should be able to put your patch into 
source.c:find_and_open_source in the part where it checks for 
  if (dirname != NULL)
    {
      ...
    }

instead of appending to the source_path, simply change the filename and
leave the source_path alone. Run this through the testsuite, are there
any errors?

I still have to think more about this to figure out how it effects GDB
searching. Anyone have any advice? For instance, I don't know if it's
significant to GDB if the dirname is relative and the filename is just
the name or if the dirname is empty and the filename is relative. Your 
suggested changes will make this fact irrelavant.

Thanks,
Bob Rossi

Re: [PATCH] Relative source file search

[Craig Jeffree]

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

On Thu, 2005-10-06 at 20:25 -0400, Bob Rossi wrote:
> Craig, you should be able to put your patch into 
> source.c:find_and_open_source in the part where it checks for 
>   if (dirname != NULL)
>     {
>       ...
>     }
> 
> instead of appending to the source_path, simply change the filename and
> leave the source_path alone. Run this through the testsuite, are there
> any errors?

Attached is a new patch with the change in find_and_open_source.  I
haven't had any luck with the testsuite though, I kept getting a build
error, then I did a cvs update to make sure I had the latest, now the
whole thing won't build.  Does the cvs head build today?  I'm getting

make[4]: Entering directory `/staff/cjeffree/gdb/gdb-cvs/src/opcodes/po'
make[4]: *** No rule to make target `ga.po', needed by `ga.gmo'.  Stop.


Cheers,
Craig.



[-- Attachment #2: relsrcsrch2.diff --]
[-- Type: text/x-patch, Size: 2929 bytes --]

Index: gdb/source.c
===================================================================
RCS file: /cvs/src/src/gdb/source.c,v
retrieving revision 1.70
diff -u -r1.70 source.c
--- gdb/source.c	29 Aug 2005 12:57:49 -0000	1.70
+++ gdb/source.c	10 Oct 2005 03:53:53 -0000
@@ -831,6 +831,7 @@
 		      char **fullname)
 {
   char *path = source_path;
+  char *file = filename;
   const char *p;
   int result;
 
@@ -847,31 +848,45 @@
 
   if (dirname != NULL)
     {
-      /* Replace a path entry of  $cdir  with the compilation directory name */
+      if (IS_ABSOLUTE_PATH(dirname))
+        {
+          /* Replace a path entry of  $cdir  with the compilation directory name */
 #define	cdir_len	5
-      /* We cast strstr's result in case an ANSIhole has made it const,
-         which produces a "required warning" when assigned to a nonconst. */
-      p = (char *) strstr (source_path, "$cdir");
-      if (p && (p == path || p[-1] == DIRNAME_SEPARATOR)
-	  && (p[cdir_len] == DIRNAME_SEPARATOR || p[cdir_len] == '\0'))
-	{
-	  int len;
-
-	  path = (char *)
-	    alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
-	  len = p - source_path;
-	  strncpy (path, source_path, len);	/* Before $cdir */
-	  strcpy (path + len, dirname);	/* new stuff */
-	  strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
-	}
+          /* We cast strstr's result in case an ANSIhole has made it const,
+             which produces a "required warning" when assigned to a nonconst. */
+          p = (char *) strstr (source_path, "$cdir");
+          if (p && (p == path || p[-1] == DIRNAME_SEPARATOR)
+              && (p[cdir_len] == DIRNAME_SEPARATOR || p[cdir_len] == '\0'))
+            {
+              int len;
+
+              path = (char *)
+                alloca (strlen (source_path) + 1 + strlen (dirname) + 1);
+              len = p - source_path;
+              strncpy (path, source_path, len);	/* Before $cdir */
+              strcpy (path + len, dirname);	/* new stuff */
+              strcat (path + len, source_path + len + cdir_len);	/* After $cdir */
+            }
+        }
+      else
+        {
+          /* Use the concatenation of dirname and filename if dirname isn't absolute */
+          file = (char *) 
+            alloca (strlen (dirname) + strlen (SLASH_STRING) + 
+                    strlen (filename) + 1);
+
+          strcpy(file, dirname);
+          strcat(file, SLASH_STRING);
+          strcat(file, filename);
+        }      
     }
 
-  result = openp (path, OPF_SEARCH_IN_PATH, filename, OPEN_MODE, 0, fullname);
+  result = openp (path, OPF_SEARCH_IN_PATH, file, OPEN_MODE, 0, fullname);
   if (result < 0)
     {
       /* Didn't work.  Try using just the basename. */
-      p = lbasename (filename);
-      if (p != filename)
+      p = lbasename (file);
+      if (p != file)
 	result = openp (path, OPF_SEARCH_IN_PATH, p, OPEN_MODE, 0, fullname);
     }
 

Re: [PATCH] Relative source file search

[Bob Rossi]

On Mon, Oct 10, 2005 at 02:56:04PM +1000, Craig Jeffree wrote:
> On Thu, 2005-10-06 at 20:25 -0400, Bob Rossi wrote:
> > Craig, you should be able to put your patch into 
> > source.c:find_and_open_source in the part where it checks for 
> >   if (dirname != NULL)
> >     {
> >       ...
> >     }
> > 
> > instead of appending to the source_path, simply change the filename and
> > leave the source_path alone. Run this through the testsuite, are there
> > any errors?
> 
> Attached is a new patch with the change in find_and_open_source.  I
> haven't had any luck with the testsuite though, I kept getting a build
> error, then I did a cvs update to make sure I had the latest, now the
> whole thing won't build.  Does the cvs head build today?  I'm getting

I'll apply this patch and run it through the testsuite. I'll also try it
on my example and let you know what the results are.

Bob Rossi

Re: [PATCH] Relative source file search

[Bob Rossi]

On Mon, Oct 10, 2005 at 02:56:04PM +1000, Craig Jeffree wrote:
> On Thu, 2005-10-06 at 20:25 -0400, Bob Rossi wrote:
> > Craig, you should be able to put your patch into 
> > source.c:find_and_open_source in the part where it checks for 
> >   if (dirname != NULL)
> >     {
> >       ...
> >     }
> > 
> > instead of appending to the source_path, simply change the filename and
> > leave the source_path alone. Run this through the testsuite, are there
> > any errors?
> 
> Attached is a new patch with the change in find_and_open_source.  I
> haven't had any luck with the testsuite though, I kept getting a build
> error, then I did a cvs update to make sure I had the latest, now the
> whole thing won't build.  Does the cvs head build today?  I'm getting
> 
> make[4]: Entering directory `/staff/cjeffree/gdb/gdb-cvs/src/opcodes/po'
> make[4]: *** No rule to make target `ga.po', needed by `ga.gmo'.  Stop.

I'm don't get this error, so I can't help you there. If it helps, I
check out GDB like this,
   cvs -d ':ext:username@sources.redhat.com:/cvs/src' co gdb+dejagnu

I ran this through the testsuite, and everything looks good. Below is the
only notable differences, hopefully someone else can elaborate on them.

Also, this change got my example working with a header file having an
inline in a relative search directory. The GDB on my system does not
find the header file, but it does after your patch. (This is of after
adding the directory of the original executable location with the 'dir'
command).

AFAIK, this patch seems good. The last problem is to find out why
sometimes the dirname is relative and the filename isn't, OR the 
filename is relative and the dirname isn't. Elena Zannoni is the general
symtab maintainer, and probably knows a good deal about this. Hopefully,
she'll let us know if she thinks this is an OK patch. I'd hate to have
the patch accepted simply because it's working by coincidence.

Finally, this patch seems to fix GDB when the dirname is relative to the
executable. What about when the dirname is relative and is linked into a
library? Then the library (from another directory) is linked into the 
executable? Does that example continue to work?

Thanks,
Bob Rossi

--- original/objdir/gdb/testsuite/gdb.sum       2005-10-10 07:07:17.000000000 -0400
+++ path/builddir/gdb/testsuite/gdb.sum 2005-10-10 07:03:42.000000000 -0400
@@ -1,4 +1,4 @@
-Test Run By bob on Mon Oct 10 06:56:48 2005
+Test Run By bob on Mon Oct 10 06:52:26 2005
 Native configuration is i686-pc-linux-gnu

                === gdb tests ===
@@ -9202,15 +9202,24 @@
 PASS: gdb.gdb/selftest.exp: set listsize to 1
 PASS: gdb.gdb/selftest.exp: run until breakpoint at captured_main
 PASS: gdb.gdb/selftest.exp: printed version as string
+PASS: gdb.gdb/selftest.exp: step over context initialization
 PASS: gdb.gdb/selftest.exp: step over argc initialization
 PASS: gdb.gdb/selftest.exp: step over argv initialization
+PASS: gdb.gdb/selftest.exp: step over symarg initialization
+PASS: gdb.gdb/selftest.exp: step over execarg initialization
+PASS: gdb.gdb/selftest.exp: step over corearg initialization
+PASS: gdb.gdb/selftest.exp: step over cdarg initialization
+PASS: gdb.gdb/selftest.exp: step over ttyarg initialization
 PASS: gdb.gdb/selftest.exp: next over get_run_time and everything it calls
 PASS: gdb.gdb/selftest.exp: next over setlocale LC_MESSAGES
 PASS: gdb.gdb/selftest.exp: next over setlocale LC_CTYPE
 PASS: gdb.gdb/selftest.exp: next over bindtextdomain
 PASS: gdb.gdb/selftest.exp: next over textdomain PACKAGE
 PASS: gdb.gdb/selftest.exp: next over lim_at_start initialization
+PASS: gdb.gdb/selftest.exp: step over cmdsize initialization
 PASS: gdb.gdb/selftest.exp: next over cmdarg initialization via xmalloc
+PASS: gdb.gdb/selftest.exp: next over ncmd initialization
+PASS: gdb.gdb/selftest.exp: next over dirsize initialization
 PASS: gdb.gdb/selftest.exp: print a string
 PASS: gdb.gdb/selftest.exp: step into xmalloc call
 PASS: gdb.gdb/selftest.exp: xgdb is at prompt
@@ -11173,7 +11184,7 @@
 PASS: gdb.threads/watchthreads.exp: watch args[1]
 FAIL: gdb.threads/watchthreads.exp: threaded watch loop
 PASS: gdb.threads/watchthreads.exp: first watchpoint on args[0] hit
-PASS: gdb.threads/watchthreads.exp: first watchpoint on args[1] hit
+FAIL: gdb.threads/watchthreads.exp: first watchpoint on args[1] hit
 FAIL: gdb.threads/watchthreads.exp: watchpoint on args[0] hit in thread
 FAIL: gdb.threads/watchthreads.exp: watchpoint on args[1] hit in thread
 FAIL: gdb.threads/watchthreads.exp: combination of threaded watchpoints = 30
@@ -11318,13 +11329,13 @@

                === gdb Summary ===

-# of expected passes           10701
-# of unexpected failures       161
+# of expected passes           10713
+# of unexpected failures       160
 # of unexpected successes      1
 # of expected failures         41
 # of unknown successes         4
 # of known failures            42
 # of untested testcases                7
 # of unsupported tests         6
-/home/bob/cvs/gdb/original/objdir/gdb/testsuite/../../gdb/gdb version  6.3.50.20051010-cvs -nx
+/home/bob/cvs/gdb/path/builddir/gdb/testsuite/../../gdb/gdb version  6.3.50.20051010-cvs -nx

Re: [PATCH] Relative source file search

[Daniel Jacobowitz]

On Mon, Oct 10, 2005 at 02:56:04PM +1000, Craig Jeffree wrote:
> make[4]: Entering directory `/staff/cjeffree/gdb/gdb-cvs/src/opcodes/po'
> make[4]: *** No rule to make target `ga.po', needed by `ga.gmo'.  Stop.

Are you missing gettext on your host system?


-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: [PATCH] Relative source file search

[Craig Jeffree]

On Mon, 2005-10-10 at 12:47 -0400, Daniel Jacobowitz wrote:
> On Mon, Oct 10, 2005 at 02:56:04PM +1000, Craig Jeffree wrote:
> > make[4]: Entering directory `/staff/cjeffree/gdb/gdb-cvs/src/opcodes/po'
> > make[4]: *** No rule to make target `ga.po', needed by `ga.gmo'.  Stop.
> 
> Are you missing gettext on your host system?

I've got gettext-0.11.4-7.  I might try a fresh checkout, I don't
remember exactly what command I checked out with, but I don't remember
the module name being gdb+dejagnu as Bob suggested.