Re: [PATCH] Relative source file search

[Craig Jeffree <craig dot jeffree at preston dot net>]

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.