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

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Hi Zack,

Thanks for your analysis.

Zack Weinberg wrote:-

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

OK, sigh.  I was hoping to get something in and refine it later.  It
is more work to work on large bodies of code that are out of CVS; and
it also means only one person can work on it.

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

Yes.

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

OK.

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

Again, I just wanted to get something working.  Things that are
complex to parse just increase complexity.  I wanted to refine stuff
later.  Indeed, lisp-ish like syntax might be good; after all we use
it everywhere else.

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

It's nicer, but makes gen-switches a lot more complex (at present it's
just a quick hack 8-)).  You need to handle optional arguments in your
scheme (that's how I handle some switches like "-g" at present, with
an "o" flag).  What would you suggest?

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

Yes, there are 2 ways to do it.  I did some one way, some the other,
for variety :-)

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

Help in it's own section might be a good idea.  If we put texinfo in
too, we'd need some way to break it into the separate menus under the
Invocation section, too.

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

OK, but is this an improvement on just making the check with a
parse_integer subroutine called from a large switch statement (much
like we do now)?

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

I think consistency shouldn't be a problem.  It's a problem with specs
simply because specs aren't C code, and so can't act on macro
definitions and variables and the like.

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

I am hoping that they are only simple transformations.  They can't be
complicated after all, because anything complicated like a new
category of switch would require a driver recompile anyway.

> 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

It's a nice idea.  Again, I don't want to attempt too much before we
have something concrete in CVS.  It just takes longer and is more
fragile.  When we have something in place, it also becomes clearer how
to refine it further.  With nothing there, there is some guesswork
involved.

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

All that logic is really easy.  Sorry I didn't explain the use of the
returned structure from parse_switches() fully, I thought it was
clear.  The structure that is filled in on return from
parse_switches() has an array (0 ... N_GROUPS-1) with one entry for
each option group, that contains the index of the first command line
argument (1 ... argc) where it appears.  Zero means didn't appear.

This allows O(1) checks if a switch appeared.  Also, Chains like -I
are easy traversible since they appear in a singly-linked list,
starting wherever this index points. [Note this would completely
remove all the crud in cppinit.c to do with appending stuff into
chains.  In fact, cppinit.c becomes a lot simpler.]

So the above SPEC would become something like

  if (array[GP_f_syntax_only] == 0
      && array[GP_stage] != 'c'       (assuming 'c' is in a stage group)
      && ...)
   do_linker_stuff ();

Since much of this conditional logic is repeated, the driver could
even put common stuff in boolean variables, like want_compiler, and
want_assembler.  That would simplify the conditional statements even
more.

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

Yes, this would be in the target-specific stuff.  Again, it's almost
trivial.

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

Not a problem I think.  I think all spec logic is easily rewritten as
simple C statements using the return values of parse_switches(), as
outlined above.  Making SPEC replacement trivial (and efficient) was
one of the main points of the exercise, to me at least.

Something else I forgot to mention - the hashtable generator flags
switches that have longer versions with SW_LONGER.  So we handle
things like -iwithprefix and -withprefixbefore without getting
confused.  After matching -iwithprefix, possibly with an appended
argument, we continue looking for a longer match.  If we succeed, that
becomes the new fall back, and we continue looking again.  Otherwise
we fall back to the most recent match.

Neil.