[distcc] Re: distcc CVS

Tim Janik timj at gtk.org
Thu Nov 7 19:22:34 GMT 2002


On Thu, 7 Nov 2002, Martin Pool wrote:

> [cc'd to list]
>
> On  7 Nov 2002, Tim Janik <timj at gtk.org> wrote:
>
> > > In fact, gdb always looks for the files relative to gdb's pwd, so if
> > > you cd to the source directory before running gdb it's OK.
> >
> > well, that doesn't quite work if your project spawns multiple directories
> > (e.g. like gtk).
>
> I think it does, if topdir-relative names are used to compile all the
> files.  If you use recursive make then you're out of luck and need to
> issue a lot of "dir" commands.

right, unfortunately, that's the standard way to compile things.
i.e. automake setups work with a simple "make" in subdirs.

> > actually no. if #line 1 "/<path>/foo.c" is the first thing fed into cpp,
> > all subsequent paths that cpp emits relative to this file, are actually
> > /<path>/ absolute, and not relative anymore.
>
> Wow, how interesting!  Thanks for pointing that out.  I can see now
> why it works.
>
> objdump shows that the original name of the file does still get in
> there, presumably since it's the first '#' line in the cpp output.
> However, gdb does look in the intended place.
>
> So this might fix it nicely.  I'll try to put it in.

not quite, i investigated this issue further, and while this fixes the
path names to the original input file, it doesn't fix up relative
includes like #include "../gdk/gdk.h". interestingly, these are
not necessarily gcc-cwd relative, but `basename $inputfile` relative,
which is a different thing if you compile sources like gcc tmp/foo.c.
the -I- option explaination in the gcc manual page mentions this.

> I wonder if we can count on cpp being able to feed from stdin, or if
> we need to create another temporary file, being just the source with
> this initial line?
>
> It may not interact well with cpp side effects like -MD, which care
> about the name of the source file.

yes, i read your distcc comment about the -MD side effect with gcc pre-3.2.
since i read that, i'm pondering another, more agressive solution ;)

> If practical, I'd rather just have it always on, rather than
> introducing another option.

well, it might be an expensive undertaking (read below) which is why
it's probably a good idea to turn absolute pathnames on only if -g
(or one of its variants) was detected in the input args.

> > > At the moment the best workaround I know is to use
> > >
> > >   dir ./src
> > >
> > > to tell gdb where to look.
> >
> > ah, yeah, that's probably going to work (modulo clashes).
> > a bit tedious with multiple libs and dirs, but yes.

since this is 1) tediuous, and 2) non-perfect if multiple subdirs
contain equally named source files, i'd call this solution at
least suboptimal, and rather get around it.

the only real solution i can come up with at this point, is
to ensure that all pathnames which end up in the object file
are absolute. this gets us around `basename $inputfile` relative
file names, and around gcc-cwd relative file names.

however, it does require the cpp output to be postprocessed
by distcc with a bit of code that does proper string escaping
(so puts("#line 2 \"xxx\" "); or similar things aren't messed up)
and prefixes any #line %u "rxxx" where r is not / with
`basename $inputfile`. this is a slightly expensive solution
as i said, because we need an extra copy of the whole file, but
it'll guarantee that no dangling paths end up in the object file,
and it'll also not break -MD.

>
> --
> Martin
>

---
ciaoTJ




More information about the distcc mailing list