Re: [RFC] Suggested replacement for specs and switch handling

["Zack Weinberg" <zackw at stanford dot edu>]

On Sun, Jun 24, 2001 at 02:14:03PM +0100, Neil Booth wrote:
> This is a long mail, so please bear with me 8-)
> 
> Back in January I proposed a rough outline of an alternative to specs
> (http://gcc.gnu.org/ml/gcc/2001-01/msg00299.html) that would resolve
> some of their shortcomings.  I'd like to outline here something more
> concrete that I've been working on, which is a bit different to what I
> had in mind in January.

I like the overall scheme, but I have a few concerns, and I'd like to
draw your attention to some other problems that should be solved at
the same time.

First, I agree with Joseph that the option table should be broken up
by front end.  It does no great harm to have an option mentioned in
multiple tables - you have to sort it anyway, so you can weed out the
duplicates then.  It will be more initial work but it will definitely
be easier to maintain.

For front ends that share lots of options, such as the C family,
perhaps we could arrange to have one file with the common options and
another with the options that are specific to one family member.

The format of gcc.switches will be difficult to extend, since you have
defined comments negatively - everything that does *not* begin with a
dash in column 1 - rather than positively.  Please use an explicit
comment introducer and reject confusing lines; then we can augment the
syntax later.

The flag letters are also going to cause confusion.  I'd like to
suggest something a bit more verbose and less cryptic.  If the time to
parse this file is significant, we have bigger problems.

For instance,

> --machine		D		sAJR	-m
> --machine-		D		jAR	-m

something like

driver {
  "--machine %"		rewrite		-m%
  --machine-%		rewrite		-m%
}

(does it ever make sense in your scheme to have R without A?  My
impression is it doesn't.)

Or, 

> -D			pt		a	+D
> -Wstrict-prototypes	COX		nB	Wstrict_prototypes
> -falign-jumps=	T		j	falign_jumps_eq
> -std=c99		pCO		n	std=STD_C99
> --shared		D		nAV	-shared

cpp,tcpp	-D%			accumulate	D
cpp,tcpp	"-D %"			rewrite		-D%
c,c++,objc	-Wstrict-prototypes	boolean		Wstrict_prototypes
backend		-falign-jumps=%		-		falign_jumps_eq
cpp,c,objc	-std=c99		-		std=STD_C99
driver		--shared		abbrev		shared

[I would rather canonicalize all switches that can appear with or
without a space before the argument, than express the concept in flag
letters.]

[For straight up aliases, where multiple options mean the same thing,
why not simply tag them all with the same group code? The
contradictory-switches-in-same-group issue can be handled through
group values only; frex, --shared and -shared both set the 'shared'
group to true, so no conflict.]


It would indeed be nice to put the help texts in this file.  We could
also express at least some of the constraints on arguments here, and
put the diagnostic messages here as well.  However, we'll lose the
nice one-line-per-option table which lets you look easily for common
features among several entries.  Maybe help belongs in its own
section:

help {
  -Dname		Define a macro with value 1
  -Dname=expansion	Define a macro with value EXPANSION
  ...
}

validate {
falign_jumps_eq  posint  Argument of "-falign-jumps" must be a positive integer.
  ...
}

This also illustrates how you may want to describe an option more
verbosely than the option table permits.

    ----

Let's not worry about consistency between preprocessor automatic
#defines and compiler settings right now.  It's a problem, yes, but it
is orthogonal to the problem of spec maintainability.  I think it will
get easier to deal with in this new scheme just because the new scheme
is easier to understand.

Concerns about losing run-time configurability are a problem.  We need
to know just what the libjava people and the embedded people need to
do with their add-on specs.  Looking at libgcj.spec, it appears to be
simply a matter of injecting extra options under certain conditions.

This brings me to my next point.  We have another chunk of code whose
function is to inject extra options under certain conditions: the
custom driver hooks.  It would be nifty if we could get rid of that.
For example, cppspec.c is a 200-line mess whose sole function is to
force -E, flip the default value of -(no-)gcc, and tweak the handling
of files with certain extensions.  I'd like to see that replaced by
something like this:

#! /usr/bin/gccdriver-3.1
# Tweaks for cpp.
stage		E
gcc		0
default-lang	c
.s		assembler-with-cpp

where the things on the left might be group labels, or extensions
which need their default interpretation tweaked.

Similarly, g++ can be expressed as

#! /usr/bin/gccdriver-3.1
# Tweaks for C++
.c		c++
.i		c++
l		-lstdc++ -lm
shared_libgcc	1

provided that there's a special hook for -l that weeds out duplicate
libraries and makes sure that -lstdc++ appears before -lm.  [I have a
Cunning Plan for collect2 that will obviate the need for any of that,
but don't hold your breath.]

[Why on earth does g++ process .c and .i files with the C++ compiler?]

    ----

You haven't said anything about two other things which are currently
handled, badly, by specs.  One is the logic which decides which
series of programs is to act on any given file.  You know, this mess:

%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %(linker) ... }}}}}}

I don't have a good idea what to do about this, but it needs to handle
-M -MF properly.

Another is the map between GCC's supposedly target-independent options
and the system-specific option set accepted by the system assembler
and linker.  For instance, -soname gets passed straight through to GNU
ld, but needs to be rewritten to -h (IIRC) for Solaris ld.  Sometimes
this map needs to make decisions.  Take a look at the various
definitions of LINK_COMMAND_SPEC in target headers.

Again, I don't have a great idea what to do with it.

-- 
zw     I was putting away groceries in our kitchen when I got to the
       cabbages and thought "this needs to be tossed into air, preferably
       without looking up first."
       	-- James Nicoll