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

[Alexandre Oliva <aoliva at redhat dot com>]

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

> Alexandre Oliva wrote:
>> Yup.  -E and -c.  That's about all they have to know.  Portable
>> options.

> Does Posix (or other standard) specify -E?

I don't know, but all C compilers support it.

> Does it specify that that compiling foo.i should be treated as a
> preprocessed C file?

It doesn't have to.  Preprocessed C is C, except for line markers and
the absence of macros.  It shouldn't matter if you preprocess again.

> The interface of cpp output file is an internal (though traditional)
> interface.  If distcc/cachecc wants to make use of an internal
> interface, it is not totally unreasonable to ask them to use
> special (optional) flags.

They don't want to use the internal interface.  It's GCC that has
used this internal interface correctly, but now it is broken.

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

> That's not necessarily our problem.

It is not GCC's problem, but GCC is the best place to fix it, since it
will then help all of ccache, distcc, compilercache, cachecc and other
compiler wrappers that are popping up.  Do you really think it's best
to keep GCC weak in this regard, forcing all such wrappers to adopt
additional non-portable command line options just because we can't
take a small additional step to get GCC to take care of the issue by
itself?

>> The compilation directory is absolutely essential for GDB to locate
>> source files without user intervention.

> Not really.  dbx and raw stabs didn't have it.  It's helpful,
> that's all.  You don't need it if, for example, debugging in the
> build directory, or if you use directory commands.

See the `without user intervention'.

And debugging in the build directory is not enough when you linked
with object files (or libraries containing object files) compiled in
multiple directories.

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

> Hm.  Looks like you're right (judging form some experiments on
> c-parse.y).  Should this be viewed as a bug in gdb - why isn't it using
> the actual (momentary) source filename?

AFAIK, these commands identify the translation unit, not necessarily
the file where the definition is.  I find this useful, since it
enables me to find out the object file in which the definition is.

> But 'info var' and 'info func' are relatively obscure commands
> (I never use them).

The fact that you never use them makes them obscure to you.  I use
them all the time.  The fact that someone took the trouble to
implement them in GDB means they're important for probably more than
one person.  This position of `I don't care about this feature because
I didn't know about it, so it's ok to break it' is very worrying :-(

> And of course using the -finput-filename and -finput-dirname options
> avoids the problem.

No, they just transfer the problem to the users, that would then have
to find ways to generate them.  They're not practical, they're not
going to be used, so they're pointless, better just take the feature
out and admit we don't want to support this.

> I agree it's a regression; though it doesn't affect debugging
> much if at all

It doesn't affect *your* debugging.  It does affect mine, otherwise I
wouldn't be pointing it out as 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.

> Internal simplification and reducing internal dependencies is
> moving forward, especially if it makes possible architectural
> changes that can improve optimization and/or compilation speed.

But the goals you've listed so far don't imply dropping of important
features.  They can (and should) be done without breaking useful
features.  It just may require a little bit of additional work to get
it right, but I value getting things right more than getting features
that are neat but that don't quite work except in laboratory
conditions.

> Besides if they pass the new flags as suggested, things would work
> as before.

Nope, you're suggesting we drop the very flag used to determine the
dump base because it would then be useless.  I'm saying it is not
useless: it's what enables users to specify the dump filenames,
regardless of the main source filename.  It should remain.

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