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

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Jun 23, 2006 at 01:10:19PM -0700, Joel Brobecker wrote:
> 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.

It is quite likely that what you really want is not "dir", but this:

  http://sourceware.org/ml/gdb/2006-03/msg00189.html

Hey, Paul...

> 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.

This might be a bug, or it might not.  But generally "dir" is used only
for files which could not be found; first try the normal location, then
try the search path.  This is the same thing we do for shared libraries
(which implies that the new command would be sort-of an analog for set
solib-absolute-prefix).  Changing anything here is tricky, because of
the case of multiple directories with files with the same name...


-- 
Daniel Jacobowitz
CodeSourcery