[distcc] Re: workaround

[Martin Pool]

This bug also affects distcc <http://distcc.samba.org/>, which I hope
will be in Debian soon.  Objects which are built on remote machines
are likely to have an incorrect compile-directory recorded in their
STABS info.

As far as I can see there are actually two possible outcomes:

 1. there are two directories containing a source file of the same
    name; gdb opens the wrong one because its directory was used to
    produce the original .o file

 2. gdb can't find the source at all

1 is more confusing because gdb would actually be "wrong", rather than
giving an error message.

I plan to ameliorate #1 in distcc by making the compile server change
into a temporary directory that is not likely to exist or contain
source on the client.  So we will only have to deal with #2.

> Yes, that will work. However in the case of a larger project, that is
> built in multiple directories, this will still be a problem.
> 
> Basically if the build system cd's into each directory, as is usual
> for anything generated with automake or other recursive make systems:
> cd dir1
> gcc file1.c -o file1.o
> cd ../dir2
> gcc file2.c -o file2.o
> 
> file1.o will contain /full/path/to/dir1 and ./file1.c as debug information,
> while file2.o will contain /full/path/to/dir2 and ./file2.c .

Yes.

gcc stores both its pwd, and the filename in the source file.  The
filename seems to come from the "# line file" pragmas in the .i file,
and it can in fact include several directory components in the case
where the source file is not in the directory the compiler is run
from.  

For example, in a VPATH build, the cdir might be
/home/mbp/work/rsync/head/build, and the filename might be
../src/access.c.

gdb seems to first try to interpret the filename relative to each of
the search directories, and if that fails, it looks in each of them
for a file matching just the basename.  (I'm not sure if that is the
exact algorithm.)

We can make the cdir irrelevant to gdb by making sure that the
filename is fully-qualified.  In this case, if the source directory
still exists, gdb doesn't need to care where the compiler was run,
because it can find the source directly.  If the source directory has
moved, then you have to specify it with "dir" anyhow -- the situation
may be a bit worse than the regular one, but the common case still
works.

So basically distcc and ccache just need to turn the source filename
on the command line into an absolute path, and that path will get into
the .i, and everything will be fine.

There will still be some edge cases, such as when distcc is run from a
directory that is unlinked, but I think they are less severe than this
bug.

-- 
Martin