[RFC] Apply compilation dir to source_path lookup

  * Mike Gulick <mgulick@mathworks.com> [2019-09-15 02:07:37 +0000]:

> On 9/14/19 11:54 AM, Eli Zaretskii wrote:
> >> Date: Sat, 14 Sep 2019 11:28:47 -0400
> >> From: Andrew Burgess <andrew.burgess@embecosm.com>
> >> Cc: mgulick@mathworks.com, gdb-patches@sourceware.org
> >>
> >> 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.
> > 
> > SGTM, thanks.
> > 
> 
> Thanks Andrew and Eli for the clarification on the proper behavior on
> DOS paths.  The only remaining questionable case for me is whether to
> check $cdir/COMP_DIR/FILENAME, which in your example above is
> 'd:/project/build/project/build/project/foo.c'.  It seems reasonable
> to me to leave this out of the search, although one could argue
> leaving it on the source path may make the documentation slightly more
> straightforward (one less special case).
> 
> Please let me know if you would like me to provide an updated version
> of the patch.

Personally I don't see it as a problem.  I agree it is unlikely to be
something that ever makes sense, but we are already trying to access
lots of paths that don't exist, I think throwing one more into the mix
isn't going to hurt.

I took another stab at the documentation, this time I've moved the
explanations for $cdir and $cwd earlier in the section - previously
these were described really late on, and it made writing the earlier
text hard as I was trying not to reference these things before they
were introduced.

The docs now focus more on some worked examples rather than trying to
just explain the algorithm in text.  I hope this is better.  I've also
included an example of how MS drive letters are handled.

On the code side I have made one change from Mike's last patch,
looking in openp at the code that glues filenames onto directories it
had three preprocessing steps:

  1. Remove drive letters (for dos),
  2. Remove leading slashes (/foo.c -> foo.c), and
  3. Remove leading './' sequences (./foo.c -> foo.c).

I've now factored these three steps out and we share them between
openp and open_and_find_source, otherwise the code is unchanged from
Mike's last patch.

Let me know what you think.

Thanks,
Andrew

---

commit 70bbf4fc4358a8c10b20faf565ab3b0dee2a20c7
Author: Mike Gulick <mgulick@mathworks.com>
Date:   Thu Sep 12 11:16:06 2019 -0400

    gdb: Look for compilation directory relative to directory search path

    The 'directory' command allows the user to provide a list of filesystem
    directories in which to search for source code.  The directories in this
    search path are used as the base directory for the source filename from
    the debug information (DW_AT_name).  Thus the directory search path
    provides alternatives to the existing compilation directory from the
    debug information (DW_AT_comp_dir).  Generally speaking, DW_AT_name
    stores the filename argument passed to the compiler (including any
    directory components), and DW_AT_comp_dir stores the current working
    directory from which the compiler was executed.  For example:

        $ cd /path/to/project/subdir1
        $ gcc -c a/test.c -g

    The corresponding debug information will look like this:

        DW_AT_name      : a/test.c
        DW_AT_comp_dir  : /path/to/project/subdir1

    When compiling with the -fdebug-prefix-map GCC option, the compilation
    directory can be arbitrarily rewritten.  In the above example, we may
    rewrite the compilation directory as follows:

        $ gcc -c a/test.c -g -fdebug-prefix-map=/path/to/project=

    In this case, the corresponding debug information will look like:

        DW_AT_name      : a/test.c
        DW_AT_comp_dir  : /subdir1

    This prevents GDB from finding the corresponding source code based on
    the debug information alone.  In some cases, a substitute-path command
    can be used to re-map a consistent prefix in the rewritten compilation
    directory to the real filesystem path.  However, there may not be a
    consistent prefix remaining in the debug symbols (for example in a
    project that has source code in many subdirectories under the project's
    root), thereby requiring multiple substitute-path rules.  In this case,
    it is easier to add the missing prefix to the directory search path via
    the 'directory' command.

    The function find_and_open_source currently searches in:

        SEARCH_PATH/FILENAME

    where SEARCH_PATH corresponds to each individual entry in the directory
    search path (which is guaranteed to contain the compilation directory
    from the debug information, as well as the current working directory).
    FILENAME corresponds to the source filename (DW_AT_name), which may have
    directory components in it.  In addition, GDB searches in:

        SEARCH_PATH/FILE_BASENAME

    where FILE_BASENAME is the basename of the DW_AT_name entry.

    This change modifies find_and_open_source to additionally search in:

        SEARCH_PATH/COMP_DIR/FILENAME

    where COMP_DIR is the compilation directory from the debug symbols.  In
    the example given earlier, running:

        (gdb) directory /path/to/project

    will now allow GDB to correctly locate the source code from the debug
    information.

    gdb/ChangeLog:

            * source.c (prepare_path_for_appending): New function.
            (openp): Make use of new function.
            (find_and_open_source): Search for the compilation directory and
            source file as a relative path beneath the directory search path.

    gdb/doc/ChangeLog:

            * gdb.texinfo (Source Path): Additional text to better describe
            how the source path directory list is used when searching for
            source files.

    gdb/testsuite/ChangeLog:

            * gdb.base/source-dir.exp: Add extra test for mapped compilation
            directory.

[RFC] Apply compilation dir to source_path lookup

Commit Message

Comments

Patch