Re: [PATCH] Relative source file search

[Bob Rossi <bob@brasko.net>]

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