Should "dir" override the full path encoded in debug info?

[Joel Brobecker <brobecker@adacore.com>]

Hello all,

One of my coworkers just attracted my attention to the semantics of
the "dir" command.

Our compiler fixes are tested through a mechanism where we submit
a patch to our testing engine. It then applies the patch to the sources
of the night before, rebuilds the compiler, reruns our testsuite, and
then send the differences. In order to facilitate the investigation
of regressions, we also make a copy of the resulting compiler in
a separate location. Once all this is completed, the nightly compiler
is restored in order to get ready for the next testing job.

My coworker tried to run the debugger using that copy of the executable
and used "dir" commands to point to his copy of the sources.
Unfortunately, that didn't work as the debugger insisted on using
the original location for getting the source files.

The issue comes from the fact that the compiler sources seem to be
compiled using full path names, or in a way that causes the AT_name
attribute of the compilation unit to be a full path.

And then, when I look at find_and_open_source(), and how it gets called
through open_source_file() (called by print_source_lines_base()), it
almost seems like it was a deliberate decision to objey the fullpath
if available rather than let the "dir" path override the debugging
info.

    /* Open a source file given a symtab S.  Returns a file descriptor or
       negative number for error.  
       
       This function is a convience function to find_and_open_source. */
    
    int
    open_source_file (struct symtab *s)
    {
      if (!s)
        return -1;
    
      return find_and_open_source (s->objfile, s->filename, s->dirname,
                                   &s->fullname);
    }   

Is that really so, or is this a bug?

Note that in most cases, we compile files using relative file names.
And under these circumstances, the "dir" path overrides the path
provided by the debugging info. This is inconsistent.

Thanks,
-- 
Joel