Re: [PATCH] Relative source file search

[Bob Rossi <bob at brasko dot net>]

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