Re: why do we need xtensa-config.h?

[augustine.sterl...@gmail.com]

On Wed, Sep 21, 2016 at 1:59 AM, Oleksij Rempel  wrote:
> So, first step is done. Our firmware is using GCC 6.2.
>
> If i see it correctly, main problem are binutils. First of all we need
> custom binutils to compile GCC assambler code with custom opcodes - it's
> a horror.
> What would be better way to solve it? Have kind of in-project plugins
> for binutils and gcc? If this is actually possible to solve it.. :(

I don't know of an easy way. A plug-in mechanism for binutils would be
a very large amount of work, and would require some pretty broad
approvals.

Re: why do we need xtensa-config.h?

[Oleksij Rempel]

Am 08.09.2016 um 19:13 schrieb Oleksij Rempel:
> Am 08.09.2016 um 18:10 schrieb augustine.sterl...@gmail.com:
>> On Thu, Sep 8, 2016 at 8:14 AM, Oleksij Rempel  
>> wrote:
>>> Am 07.09.2016 um 18:21 schrieb augustine.sterl...@gmail.com:
 On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
  wrote:
> Hi!
>
> 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 
>  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?
>> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.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.
>>>
>>> The point is to provide a package for "free" repository. It means, any
>>> one should be able to use "apt-get source package_name", patch it and
>>> recompile it from source.
>>>
>>> Right now it would work, but the package scripts should download
>>> toolchain source, patch and compile it and the compile actual firmware.
>>> This is wary high overhead.
>>>
>>> This is why i asked my self, why the toolchain can't be modular or
>>> configurable enough to work without patching and recompiling it.
>>>
 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.
>>>
>>> after quick look i noticed that:
>>> XSHAL_USE_ABSOLUTE_LITERALS affects TRAMPOLINE_SIZE. This seems to be
>>> hardcoded every where in gcc, so can't be changed dynamically?
>>
>> TRAMPOLINE_SIZE is used in quite a few places (so beyond my authority
>> to accept patches), but I suspect it would be acceptable to put a
>> function behind TRAMPOLINE_SIZE that calculated the value dynamically.
>>
>>>
>>> XCHAL_HAVE_MUL32_HIGH 

Re: why do we need xtensa-config.h?

[Oleksij Rempel]

Am 08.09.2016 um 18:10 schrieb augustine.sterl...@gmail.com:
> On Thu, Sep 8, 2016 at 8:14 AM, Oleksij Rempel  wrote:
>> Am 07.09.2016 um 18:21 schrieb augustine.sterl...@gmail.com:
>>> On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
>>>  wrote:
 Hi!

 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  
 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?
> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.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.
>>
>> The point is to provide a package for "free" repository. It means, any
>> one should be able to use "apt-get source package_name", patch it and
>> recompile it from source.
>>
>> Right now it would work, but the package scripts should download
>> toolchain source, patch and compile it and the compile actual firmware.
>> This is wary high overhead.
>>
>> This is why i asked my self, why the toolchain can't be modular or
>> configurable enough to work without patching and recompiling it.
>>
>>> 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.
>>
>> after quick look i noticed that:
>> XSHAL_USE_ABSOLUTE_LITERALS affects TRAMPOLINE_SIZE. This seems to be
>> hardcoded every where in gcc, so can't be changed dynamically?
> 
> TRAMPOLINE_SIZE is used in quite a few places (so beyond my authority
> to accept patches), but I suspect it would be acceptable to put a
> function behind TRAMPOLINE_SIZE that calculated the value dynamically.
> 
>>
>> XCHAL_HAVE_MUL32_HIGH probably can be changed dynamically.
>> XCHAL_ICACHE_SIZE and XCHAL_DCACHE_SIZE will enable or disable part of
>> __xtensa_sync_caches, why not to make it 

Re: why do we need xtensa-config.h?

[augustine.sterl...@gmail.com]

On Thu, Sep 8, 2016 at 8:14 AM, Oleksij Rempel  wrote:
> Am 07.09.2016 um 18:21 schrieb augustine.sterl...@gmail.com:
>> On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
>>  wrote:
>>> Hi!
>>>
>>> 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  
>>> 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?
 https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.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.
>
> The point is to provide a package for "free" repository. It means, any
> one should be able to use "apt-get source package_name", patch it and
> recompile it from source.
>
> Right now it would work, but the package scripts should download
> toolchain source, patch and compile it and the compile actual firmware.
> This is wary high overhead.
>
> This is why i asked my self, why the toolchain can't be modular or
> configurable enough to work without patching and recompiling it.
>
>> 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.
>
> after quick look i noticed that:
> XSHAL_USE_ABSOLUTE_LITERALS affects TRAMPOLINE_SIZE. This seems to be
> hardcoded every where in gcc, so can't be changed dynamically?

TRAMPOLINE_SIZE is used in quite a few places (so beyond my authority
to accept patches), but I suspect it would be acceptable to put a
function behind TRAMPOLINE_SIZE that calculated the value dynamically.

>
> XCHAL_HAVE_MUL32_HIGH probably can be changed dynamically.
> XCHAL_ICACHE_SIZE and XCHAL_DCACHE_SIZE will enable or disable part of
> __xtensa_sync_caches, why not to make it dynamically as command line option?
>
>
> IMO most of xtensa-config.h can be changed on runtime. Or do i miss some
> thing?

Unless we can make it all of what xtensa-config.h 

Re: why do we need xtensa-config.h?

[Oleksij Rempel]

Am 07.09.2016 um 18:21 schrieb augustine.sterl...@gmail.com:
> On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
>  wrote:
>> Hi!
>>
>> 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  
>> 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?
>>> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.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.

The point is to provide a package for "free" repository. It means, any
one should be able to use "apt-get source package_name", patch it and
recompile it from source.

Right now it would work, but the package scripts should download
toolchain source, patch and compile it and the compile actual firmware.
This is wary high overhead.

This is why i asked my self, why the toolchain can't be modular or
configurable enough to work without patching and recompiling it.

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

after quick look i noticed that:
XSHAL_USE_ABSOLUTE_LITERALS affects TRAMPOLINE_SIZE. This seems to be
hardcoded every where in gcc, so can't be changed dynamically?

XCHAL_HAVE_MUL32_HIGH probably can be changed dynamically.
XCHAL_ICACHE_SIZE and XCHAL_DCACHE_SIZE will enable or disable part of
__xtensa_sync_caches, why not to make it dynamically as command line option?


IMO most of xtensa-config.h can be changed on runtime. Or do i miss some
thing?

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

Re: why do we need xtensa-config.h?

[augustine.sterl...@gmail.com]

On Wed, Sep 7, 2016 at 9:21 AM, augustine.sterl...@gmail.com
 wrote:
> Hope this helps, and I'm happy to answer more questions.

Also, one technique commonly used by people who ship software for
Xtensa is to write it such that it could compile for any variant at
all. This requires care, but is quite doable.

Re: why do we need xtensa-config.h?

[augustine.sterl...@gmail.com]

On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge
 wrote:
> Hi!
>
> 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  
> 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?
>> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.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.

Re: why do we need xtensa-config.h?

[Max Filippov]

Hello,

On Tue, Sep 6, 2016 at 11:42 AM, Oleksij Rempel  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?
> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.patch

Yes, these changes are needed, but perhaps not in a form of a patch.
The changed file is a part of the configuration overlay that need to be
applied to binutils, gcc and gdb in order to configure them to generate
code for the specific xtensa core.
We have xtensa support in the crosstool-NG and the Buildroot, both
of which can generate xtensa toolchain using configuration overlay.
Please refer to
 http://wiki.linux-xtensa.org/index.php/Toolchain_and_Embedded_Distributions
for more information about xtensa configuration overlay and its usage
by crosstool-NG and Buildroot.

> Is it possible or welcome to extend gcc to be configurable without
> patching it all the time?

It is definitely welcome and is likely possible.
Please do not forget that both gcc and binutils need to have coherent idea
of the processor they're generating code for.

-- 
Thanks.
-- Max

Re: why do we need xtensa-config.h?

[Thomas Schwinge]

Hi!

Neither do I really know anything about Xtensa, nor do I have a lot of
experience in these parts of GCC back ends, but:

On Tue, 6 Sep 2016 20:42:53 +0200, Oleksij Rempel  
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?
> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.patch

That I can't tell.  ;-)

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

This file include/xtensa-config.h is #included in
gcc/config/xtensa/xtensa.h and libgcc/config/xtensa/crti.S,
libgcc/config/xtensa/crtn.S, libgcc/config/xtensa/lib1funcs.S,
libgcc/config/xtensa/lib2funcs.S, but I have not checked how the macro
definitions are actually used.

In gcc/doc/install.texi I read:

@anchor{xtensa-x-elf}
@heading xtensa*-*-elf
This target is intended for embedded Xtensa systems using the
@samp{newlib} C library.  It uses ELF but does not support shared
objects.  Designed-defined instructions specified via the
Tensilica Instruction Extension (TIE) language are only supported
through inline assembly.

The Xtensa configuration information must be specified prior to
building GCC@.  The @file{include/xtensa-config.h} header
file contains the configuration information.  If you created your
own Xtensa configuration with the Xtensa Processor Generator, the
downloaded files include a customized copy of this header file,
which you can use to replace the default header file.

@html

@end html
@anchor{xtensa-x-linux}
@heading xtensa*-*-linux*
[...]

Hmm.  CCing Sterling Augustine who is listed as the Xtensa CPU Port
Maintainer.


Grüße
 Thomas


signature.asc
Description: PGP signature