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:
>> Who would tell it?  distcc and ccache know nothing about the compiler,

> Obviously they know enough about the compiler and its options to
> run the preprocessor and compiler proper separately.

Yup.  -E and -c.  That's about all they have to know.  Portable
options.  -fsource-filename certainly isn't.  Most compilers would
barf at it.

>> they just run whatever the user told them to, so it can't add command
>> line flags that some compilers might not support.

> That can be handled by the configure script checking if
> the new option is recognized.

Huh?  Whose configure script?  distcc?  ccache?  As if they could only
be used with one compiler?  See, I'm using distcc for compiler
bootstraps.  How am I supposed to be able to build a custom gcc with a
compiler that has just been built?  The beauty of these tools is that
you can tell them to run whatever compiler you like, and they just
work.  Asking for them to be configured for different compilers would
make them a major pain to use.

> An alternative is to use environment variables instead of flags.

It still doesn't offer the correct behavior out of the box, as it did
before it was broken.

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

> The distcc client.

Not going to happen.

> I'm proposing:

>    DIR=`pwd`
>    gcc -flags source.c -E > /tmp/tmpXXX.i
>    (cd /tmp && gcc -fsource-name source.c -fworking-directory $DIR
> -flags tmpXXX.i -c -o tmpXXX.o)
>    mv /tmp/tmpXXX.o source.o

These command line options are not portable, so ccache and distcc, or
any other compiler wrapper, won't use it.

> This does not seem unreasonable

Sorry, it is.  If you don't think so, you've probably never used these
tools, and just don't understand the principles behind them.

>> You seem to be willing to give up correct information in favor of
>> generating a single object file out of multiple sources.

> No, I don't think so.  Besides it's not just me and the compile
> server.  There is also the "intermodule" work, which is important
> for cross-module optimization.

I'm not arguing against any of that.  I'm saying that correct
debugging information shouldn't be given up in favor of these new
features.

> Functionally equivalent.  It doesn't have to be identical.

Right.  Mentioning only one source file surely isn't functionally
equivalent if you're compiling multiple source files.

> The "main_input_filename" appears in the object file, but it isn't
> really needed for anything.  The "compilation direction" is useful
> for finding source file (for the 'list' command), but is obviously
> not essential.  (Not that I'm arguing for leaving it out, of course.)

The compilation directory is absolutely essential for GDB to locate
source files without user intervention.  The main input filename is
absolutely essential for GDB's `info var' or `info func' to list the
actual source filename when you use ccache or distcc or -save-temps in
a compilation; currently, all you get is some random .i filename.
Ugly and broken.

> Yes, in principle.  However, certain debug format make that
> difficult if doing a multi-module compile.

If you can link together multiple translation units, especially with
-r, there must be a way to generate such debug info properly from the
compiler.  It doesn't have to be easy; it may involve tweaking the
assembler to accept such info.  But IMHO it's far better than
generating incorrect or incomplete debug info.

> And the latter
> is more important, as it enables cross-module optmizations,
> and the translation unit identifier isn't really used for anything.

A debugger used it.  Guess what is the tool designed to consume debug
information?  If you break it, you break the debugger.

See, I'm not arguing against cross-module optimization.  I just don't
want to end up with undebuggable programs because of such
optimizations.

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

> It can be done by using the command line flags for the initial debug
> info, as I'm suggesting.

Command line flags like these are useless.  The programs you'd like to
have changed to pass them won't do that, and shouldn't do that.  GCC
has been able to figure out the main input filename forever, and now
it doesn't; this is a major regression.  GCC has been able to figure
out the preprocessing source directory from Aug 5 to Oct 1 last year,
now it doesn't; this is a minor regression.  Introducing regressions
is not moving forward.

> Because that matches the output when compiling directly from source,
> which I thought is what you wanted.

This is one of the cases in which the tools will assume they can't do
their magic.  Even though they limit themselves to interacting with
compilers in a portable way, they do know of command line flags that
may affect certain compilers in ways they can't control, and run the
compiler directly in such cases.

What should match the output when compiling directly is something as
simple as separate preprocessing with -E then compilation of the
preprocessed file.  No odd options.

> Because the exact names of the dump files isn't very important, so
> it seems wasteful to have a special flag for it.

Isn't very important to whom?

Assume that a tool actually took the trouble of supporting remote
compilation using gcc with dumping.  It took the trouble to figure out
how GCC names the files, and proceeds accordingly.  Now you change the
names from under it, and the tool is broken.  Not nice, eh?

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