This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Let's kill specs, completely rewrite gcc.c
- To: Neil Booth <neilb at earthling dot net>
- Subject: Re: [RFC] Let's kill specs, completely rewrite gcc.c
- From: Michael Meissner <meissner at cygnus dot com>
- Date: Sun, 7 Jan 2001 17:38:00 -0500
- Cc: gcc at gcc dot gnu dot org, "Chris G . Demetriou" <cgd at sibyte dot com>
- References: <20010107131442.B24550@daikokuya.demon.co.uk>
On Sun, Jan 07, 2001 at 01:14:42PM +0000, Neil Booth wrote:
> Over the last 3 months, changes to cpplib have required updating the
> SPECS handling in gcc.c. For example, to fix the meaning of '|', and
> to preserve order of -D and -U on the command line. I think yet
> another spec may be required, similar to what Nathan posted last week,
> for me to handle -MD and -MMD correctly - path preservation but suffix
> replacement.
>
> A few mails last November with Chris Demetriou inspired me to think of
> better way of doing things. It strikes me that most patches to gcc.c
> are simply kludges on top of an already gross kludge, and that the
> spec-parsing part of gcc.c is hard to follow. However, I don't know
> the historical reasons for specs being the way they are, so I may be
> missing something.
I hate to be a kill joy, but specs are quite heavily used, especially by
embedded programers, and I would oppose removing them without providing an
adequate substitute that does not involve rebuilding the gcc driver (cleaning
them up, fixing them, etc. is certainly no problem, though I would argue that
any changes need to be upwards compatible).
The main use of specs in this case, is to override the default libraries,
crt0s, etc. for an environment that is similar to but not the same as the
default GCC environment. For example, consider a GCC compiler targeting say
the PowerPC (or ARM, x86, etc.). There are a number of different target boards
(and ultimately each unique embedded device) made by different vendors. On
long development cycles, a target board may be created and then obsoleted
between GCC releases. With specs, either the board company or a third party
like Red Hat, can provide a replacement environment for each new board by just
providing a specs file without modifying the base compiler.
Here is the specs file used for one of the PowerPC MBX boards:
%rename lib old_lib
%rename cpp old_cpp
%rename link old_link
*lib:
--start-group -lmbxbsp -lc -lgcc --end-group %(old_lib)
*cpp:
-D__MISSING_SYSCALL_NAMES__ -D__CPU_MPC8XX__ -D__BOARD_MBX__ %(old_cpp)
*startfile_default:
ecrti%O%s mbx-crt0%O%s
*endfile_default:
ecrtn%O%s
*link:
-T bsp.ld%s -Ttext 0x10000 %(old_link)
A second use of specs is to use a common driver file to invoke older compiler
tool chains (ie, with -V). If the processing is built in, then this will not
be viable.
A third use of specs is to override default options on a local basis, but
editing the specs file.
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: meissner@redhat.com phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482