Re: -save-temps still produces different .s and .o

[Alexandre Oliva <aoliva at redhat dot com>]

On Jan 14, 2004, Per Bothner <per@bothner.com> wrote:

> Alexandre Oliva wrote:
>> The thing about distcc is that compilation occurs on a separate
>> machine, that doesn't even have access to the cwd in which
>> preprocessing occurred,

> Yes, but it can be *told* the cwd in which preprocessing occurred,
> just as it can told the necessary compiler flags.

Who would tell it?  distcc and ccache know nothing about the compiler,
they just run whatever the user told them to, so it can't add command
line flags that some compilers might not support.

> You're right.  It looks like we need a different flag.  Or
> modify -dumpbase to pass the full name.  If we pass in the
> full source file name, do we really need a separate -dumpbase?

Again, who would figure out the full source file name to pass to the
compiler?

> The cache would have to match using the compilation directory, just as
> (I assume) it has to match other compilation flags.

ccache has an option for that.  But how about distcc?

> My suggestion would support those needs, in a simpler and more
> flexible manner.

Except it would require these tools to adapt to specific features of
specific compilers, something they shouldn't have to do, since the
additional overhead would partially obviate the speed up that these
tools are meant to offer.  The compiler has to be able to figure this
information out by itself, otherwise it won't work, in a scenario like
this:

where you'd run:

  gcc -flags source.c -c -o source.o

you run instead:

  gcc -flags source.c -E > /tmp/tmpXXX.i
  (cd /tmp && gcc -flags tmpXXX.i -c -o tmpXXX.o)
  mv /tmp/tmpXXX.o source.o

if this doesn't produce the same object file as the single
translation, then it's useless for ccache and distcc, especially for
distcc.

> I don't see how passing the real
> file name or directory as options rather than embedded in the cpp
> output is a problem.

The problem is who would pass them.  Surely you're not suggesting the
compiler driver to peek into the preprocessed input files to figure
out the original source file, in the compilation of source.i, are you?

> Yes, my proposal requires some simple changes to distcc/cachecc, but
> it simplifies gcc itself.

These changes are not simple at all.  They totally disrupt the
functioning of these tools, since they can't just assume any compiler
they get in the command line accepts these flags.  It means they'd
have to probe the compiler pretty much for every compilation.  And if
you insist it should do this, how about several other compiler-probing
it could do?  When is too much too much?

> Because before we had a single execution of cc1 read a single
> main input file and create a single assembler output file.
> We are now trying to support:
> (a) creating a single assembler file from multiple main input files.
> (b) creating multiple assembler files from a single cc1 executable.

> Consider (a).  We need to write the main_input_filename and src_pwd
> at the start of the assembler file (at least for stabs).  This
> means we would have to open and partially read the first
> input file before starting the assembler file, but open and
> read the subsequent input files later.  This does not lead
> to nice program flow.

You seem to be willing to give up correct information in favor of
generating a single object file out of multiple sources.  I don't
think this is a reasonable trade off.  If you are compiling multiple
translation units, the debug info you get should be functionally
equivalent to that you'd get by compiling and assembling multiple
translation units separately, then running ld -r to merge them into a
single object file.  I.e., the debug info should reflect the fact that
there are multiple translation units involved, that there are multiple
main source files.

If you think you should output the translation unit identifier for
only the first translation, I have failed to communicate what I have
in mind.  IMO, it should be done for every main input file.

> We are also supporting languages that don't use cpp.  So we're
> adding a bunch of complication to handle a need that can be
> solved more cleanly otherwise.

Sure enough adding a function call to the beginning of the parse
function, to use a pointer passed to it that would otherwise get a
warning about being unused, isn't such a major problem, is it?

> I can turn the question back on to you:  How can a simple call to an
> initialization function be such a big deal?  Why can't you fix
> -fworking-directory without re-organizing (reverting) the code?

Because it can't be done.  If we output the initial debug info before
knowing the name of the real source file, we're emitting incorrect
debug info.  And this is what we do now.  It's broken.

> Because there are complicated and ugly inter-dependencies, that's why.

Exactly.  And some attempt to simplify them oversimplified them to the
point of breaking them.

> * Applications that call gcc -fpreprocssed may need to pass the
> above options.

FWIW, neither ccache nor distcc use -fpreprocessed.  GCC is clever
enough to realize it has a preprocessed source file because of the .i
or .ii extension.

> * Possibly remove -dumpbase, since we can use main_input_filename
> after stripping directories.

It's not the same.  Consider:

  gcc -fpreprocessed test.i -fsource-name /path/to/src/foo.c \
    -fworking-directory /path/to/build -da -o bar.o

What should the dump file names look like?  Current compiler generates
test.i.*.  Your suggestion would change it to foo.c.*.  Why is such a
change a good thing?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year!                     oliva@{lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist                Professional serial bug killer