This is the mail archive of the gcc-patches@gcc.gnu.org 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


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

> Alexandre Oliva wrote:
>> It turns out that -fworking-directory was totally disabled with a
>> patch that Per Bothner installed on Oct 1.  I'd noticed make bootstrap
>> with distcc stopped working, but only today have I been able to
>> investigate why.

> It's hard to duplicate the "old" behaviour, because the "old" behavior
> is not in 3.3.

Right.  After more than 1 year trying to get the patch in, it went
into mainline on Aug 5, just to be broken less than 2 months later :-(

This behavior is absolutely necessary in order for ccache and distcc
to work properly.  -save-temps is just the simpler way to expose the
problems you get with separate preprocessing and compilation, that any
tool like ccache and distcc end up running into.

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, but it still should generate the same object
file that would have been generated should the compilation have
occurred on the machine where distcc was started.

>> It turns out that we no longer see the main input filename early
>> enough when compiling a file that was already preprocessed,

> I remember looking at some of this code, but without a testcase
> (and not really knowing what it was for) I can easily have broken it.

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

> Unfortunately, the old mechanism of trying to get the "real" main
> input filename by peeking at the first file of the preprocessed file
> was a bit of a kludge

It was relying on long-standing GCC behavior, that several tools have
come to rely on.  Breaking this property is probably a very bad idea.
Yes, I agree it makes for difficulties, but I don't really see a way
around it (see below).

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

> I suggest doing something similar for the working directory.
> So instead of extending the cpp file format, and adding the
> -fworking-directory option, I think it would be easier to
> have a cc1 command-line option that just calls set_src_pwd.

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

> This seems a much simpler solution and does not constrain
> the initialization logic of the compiler.

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.

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

>> The only way I see to fix this problem is to arrange for all front
>> ends to call the init code from within their parse code, after they
>> find out the real main_input_filename.  I.e., lang_dependent_init(),
>> init_final() and coverage_init() would no longer be called in toplev.c
>> before lang_hooks.compile_file, but rather within their code.  Would
>> such a change be acceptable?

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

How come it worked before?  How can a simple call to an initialization
function be such a big deal?

>> Meanwhile, here's the patch that restores at least identical debug
>> info with and without -save-temps.  Per, does any of this conflict
>> with your needs?

> It conflicts with the long-term needs of the compile-server, whenever
> that would get merged in.

What are such needs?

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?

> I'm willing to implement my solution.  This would include removing
> the implementation and documentation of -fworking-directory.

This would be a major regression IMHO.  It would once again make
distcc unusable for GCC bootstraps :-(

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


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