Re: [RFC] Apply compilation dir to source_path lookup

[Andrew Burgess <andrew.burgess@embecosm.com>]

* Eli Zaretskii <eliz@gnu.org> [2019-09-14 09:56:35 +0300]:

> > Date: Fri, 13 Sep 2019 18:45:35 -0400
> > From: Andrew Burgess <andrew.burgess@embecosm.com>
> > Cc: mgulick@mathworks.com, gdb-patches@sourceware.org
> > 
> > > Btw, do the "prepend" and "append", as implemented, take care to DTRT
> > > with Windows drive letters at the beginning of absolute file names?  A
> > > literal prepending or appending will do the wrong thing there.
> > 
> > Gah!
> > 
> > Looking at the implementation of 'openp' (in source.c) I see this
> > code:
> > 
> >   /* For dos paths, d:/foo -> /foo, and d:foo -> foo.  */
> >   if (HAS_DRIVE_SPEC (string))
> >     string = STRIP_DRIVE_SPEC (string);
> > 
> > which just seems to throw out the drive spec, and I can't find any
> > code that adds it back in.  Is that going to do the right thing?
> 
> I'm not sure we are talking about the same thing.  My concern is
> specifically this use case mentioned in your description:
> 
>   SEARCH_PATH/COMP_DIR/FILENAME
> 
> What will happen here if both SEARCH_PATH and COMP_DIR are absolute
> file names (which on Windows means they have drive letters)?  AFAIU on
> Unix you will concatenate them, so we need some kind of
> "concatenation" on Windows as well, but that means one of the drive
> letters should "win".  Which drive letter wins in this case, and will
> the result make sense from the user perspective?

If we get as far trying this merge then the drive letter on COMP_DIR
will be removed and we use whatever is on SEARCH_PATH.  This is
exactly the same as what we've always done if FILENAME is itself
absolute.

The code I pointed out above that last night I didn't understand now
makes perfect sense.

If we have:

   DW_AT_name:  	c:/project/foo.c
   DW_AT_comp_dir:	d:/project/build/

And if the directory search path is:

   g:/mnt/project;$cdir;$cwd

And the current directory is:

   h:/home/

Then this is what I think the search order will be:

   c:/project/foo.c
   g:/mnt/project/project/foo.c
   d:/project/build/project/foo.c
   h:/home/project/foo.c

   d:/project/build/project/foo.c
   g:/mnt/project/project/build/project/foo.c
   d:/project/build/project/build/project/foo.c
   h:/home/project/build/project/foo.c

   g:/mnt/project/foo.c
   d:/project/build/foo.c
   h:/home/foo.c

The first and third block is what we currently (pre-patch) do, and the
second block is what I think the patch should provide after Mike's
last suggested update.

> 
> It is clear to me that if FILENAME is absolute, we don't use any of
> the directories to locate it, neither on Unix nor on Windows.  Right?

Well.... if FILENAME is absolute then that will get tried first, which
for most developers will work fine.  But we also want to support the
possibility that people might relocate the source tree into source
other location.  So if you compile /project/foo-1.0/f1.c the
DW_AT_name will be that absolute path, if you then moved that source
tree into: '~/.debug-cache/foo/project/foo-1.0/f1.c' we still want to
allow that to be found which requires prefixing the absolute path with
a directory.

I guess on Windows if the absolute file path include a 'c:' prefix,
but you relocated the source into a location below 'd:' then you want
the 'c:' prefix stripped off, which is what would happen at the
moment, so I think all is good.

Thanks,
Andrew