This is the mail archive of the
mailing list for the GCC project.
Re: why do we need xtensa-config.h?
- From: "augustine dot sterling at gmail dot com" <augustine dot sterling at gmail dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Oleksij Rempel <linux at rempel-privat dot de>, Adrian Chadd <adrian at freebsd dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 7 Sep 2016 09:21:30 -0700
- Subject: Re: why do we need xtensa-config.h?
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <email@example.com>
On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
> Neither do I really know anything about Xtensa, nor do I have a lot of
> experience in these parts of GCC back ends, but:
There is a lot of background to know here. Unfortunately, I have no
familiarity with making debian packages, so I'm unfamiliar with that
side of it.
First--and perhaps most important--the current method of configuring
GCC for xtensa targets has worked well for nearly two decades. As far
as I know, it is rare to encounter problems. Because of that, the bar
to change it will probably be fairly high to change it.
> On Tue, 6 Sep 2016 20:42:53 +0200, Oleksij Rempel <firstname.lastname@example.org> wrote:
>> i'm one of ath9k-htc-firmware developers. Currently i'm looking for the
>> way to provide this firmware as opensource/free package for debian. Main
>> problem seems to be the need to patch gcc xtensa-config.h to make it
>> suitable for our CPU.
>> I have fallowing questions:
>> do we really need this patch?
> That I can't tell. ;-)
You need something like that patch, for sure.
>> Is it possible or welcome to extend gcc to be configurable without
>> patching it all the time?
> Yes, I would think. The macros modified in the above patch to GCC's
> include/xtensa-config.h file look like these ought to be modifiable with
> -m* options defined by the Xtensa back end, and you'd then assign
> specific defaults to a specific CPU variant, and build GCC (or build a
> multilib) for that configuration.
Today, there are literally hundreds of variants of the xtensa cpu
actually realized and in use. Having a list of all those variants and
their defaults inside gcc would be awkward and unwieldy.
But--and here's the rub--literally tomorrow, someone could design a
hundred more that are different from all of the ones already out
there. There is literally an unlimited number of potential variants,
each with potentially brand new, never conceived instructions. (Adding
clever custom instructions is xtensa's raison d'etre.)
With the current configurability mechanism, supporting all of those
variants inside gcc (and, in fact, the rest of the gnu-toolchain) is
simply a matter of using the correct xtensa-config.h for that
particular variant. If we were to go with the "-m with defaults"
mechanism, we would need some way of adding the defaults for the new
variant to gcc.
But that is patching gcc also, and once you go there, you may as well
use the original method.
> This file include/xtensa-config.h is #included in
> gcc/config/xtensa/xtensa.h and libgcc/config/xtensa/crti.S,
Note that "-m" options can't change the instructions in crti.S and
lib?funcs.S, but macros can and do.
On the debian packaging side. Forgive me for my ignorance on the
topic; I don't know that the tool-flow is, or what the requirements
are. As far as I am aware, this is the first time someone has tried to
make a debian package for xtensa.
Anyway, I wouldn't expect patching gcc (or configuring it) for an
individual package is the right thing. It should probably happen as
part of some kind of "setup toolchain" step.
Typically, patching gcc for a xtensa config happens just once
immediately after designing the processor, or--if you aren't the
designer yourself--when one starts development for that variant.
Surely if someone is building this package, they would have already
built some other software for that particular xtensa target. (Perhaps
as part of a larger debian build?)
Also, this package should probably only be built when targeting this
particular xtensa variant (not xtensa generally). I don't know how one
restricts this in the debian packaging mechanism.
Hope this helps, and I'm happy to answer more questions.