Re: [PATCH] Relative source file search

[Bob Rossi <bob@brasko.net>]

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