This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

> I don't see how we could possibly have a testcase for this.  I wish I
> knew of one, really.

We could have a testcase that -fworking-directory creates output
in an expected format.  We could also have a testcase that the
compiler can read this properly, but that is harder.

What I did in the compile server branch was get the "real" main
input filename by using the -dumpbase option.

This is not the real main input filename. dumpbase doesn't have pathname components, and if you compile a preprocessed file, it has no idea of what the name of the file that had been preprocessed before is. And, guess what, the name of the original filename is exactly the information you want to have in the debug info.

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?

Problem is you'd have to know what the working-directory is, i.e.,
tools such as ccache and distcc would no longer get it as a side
effect of preprocessing.  It means ccache, for example, would still
get a cache hit even when a file is preprocessed in a different
directory, meaning the cached object file will be used even though the
debug information in it points to a build tree that may be
significantly different.  This is confusing, so it shouldn't be the

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

It's so simple that it doesn't satisfy the needs that justified the
implementation in the first place.  Sure, we don't have to support
ccache and distcc, but these are very useful tools, and at some point
we did, and now it's broken again, and although your suggestions would
fix the -save-temps case, they won't fix the real issue, which is
separate preprocessing and compilation.

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

For the option for the directory name, we can invent a new
one or overload the -dumpbase option (just like stabs overloads
N_SO).  I.e.:
  cc1 -dumpbase ORIG_DIR_NAME/ -dumpbase ORIG_FILE_NAME foo.i ...

This won't help because when the compiler is run by distcc or ccache,
the preprocessing directory is not necessarily known.

Both of these have to be passed (in addition to the preprocessed output) a set of compilation flags. The use flags have to be consistent with the state when preprocessing was done. I don't see how passing the real file name or directory as options rather than embedded in the cpp output is a problem. Yes, my proposal requires some simple changes to distcc/cachecc, but it simplifies gcc itself.

No.  There are too many dependencies in the compiler and this would
make it worse.

How come it worked before?

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.

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.

How can a simple call to an initialization
function be such a big deal?

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 there are complicated and ugly inter-dependencies, that's why.

That is not to say we must discount this option.  It should be
possible to modify the compiler so that it can set main_input_filename
and src_pwd from the .i file, assuming we only need this when
-fpreprocessed, without breaking the compile server needs.  How
big such a change it would be I don't know.  It might mean that
initialization happens in a different order depending on
-fpreprocessed, which could be a source of bugs.

Surely you're not saying they should override the premise that the
maintainers of the preprocessor imposed on me, which is that
preprocessing an already preprocessed file should be a do-nothing
operation?  Surely it shouldn't override the desire to generate
correct and useful debug information?

You have not convinced me that my approach hinders those goals.

To re-phrase my proposal:

* Add (or overload) an option to set the main_input_filename.
* Add (or overload) an option to set src_pwd.
* Applications that call gcc -fpreprocssed may need to pass the
above options.
* Remove -fworking-directory, as it is no longer needed.
* Remove the logic for trying to set main_input_filename from
an input file.
* Possibly remove -dumpbase, since we can use main_input_filename
after stripping directories.
	--Per Bothner

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]