arch: not all have support in the internal backend
cover arch: not all have support in the internal backend
Hello All!
Not all architectures we support have support in upstream gcc, glibc, binutils, and/or linux. In some cases, only a few specific cores do not have that support.
Furthermore, some architecture, specific cores, or core behaviour/setup (like the MIPS NaN support) got support in a specific gcc version.
Currently, we have to account for this in at least three locations:
- the toolchain backend choice (internal or externsal)
- the gcc version choice
- each external toolchain
This series is a first step, to introduce the possibility for each architecture, or specific core thereof, to specify that it lacks support in our internal backend.
The logic is indeed a negative logic, which we usaual try to avoid in Buildroot. However, the vast majority of architectures and individual cores do have support with our internal backend; only a few of them don't, and using positive logic would have meant that that vast majority would have had to add a new 'select'.
The case for the gcc version will be handled in a follow-up series, while the MIPS NaN fixes will ber in their own further follow-up.
Regards,
Yann E. MORIN.
The following changes since commit e8bcc8ad93745ea9bdcd13c076fec1f3e27b9dee
cgilua: bump to version 5.2.1 (2017-09-02 20:17:24 +0200)
are available in the git repository at:
git://git.buildroot.org/~ymorin/git/buildroot.git
for you to fetch changes up to 8cc068d0be7bb232bfbd3bb3c67dc01b476f3297
arch/mips: internal backend not suitable for some cores (2017-09-02 21:34:30 +0200)
----------------------------------------------------------------
Yann E. MORIN (4):
arch: add option to disable internal toolchain backend arch/csky: internal backend not suitable arch/bfin: internal backend not suitable for some cores arch/mips: internal backend not suitable for some cores
arch/Config.in | 7 +++++++ arch/Config.in.bfin | 4 ++++ arch/Config.in.mips | 2 ++ toolchain/Config.in | 8 +------- 4 files changed, 14 insertions(+), 7 deletions(-)
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/4 arch: add option to disable internal toolchain backend
Some architectures or specific cores do not have support in upstream gcc. Currently, they are individually listed as exclusions in the toolchain choice.
This poses a maintainance burden, as the knowledge about what gcc version supports what architecture is split across many places: the toolchain choice, the gcc version choice, the external toolchains.
As a first step, add a blind option that architectures or individual cores may select to indicate they lack support in our internal backend.
Yes, the logic is inverted, because the very large majority of archs and cores do have support in upstream gcc (or in a vendor fork we support, like bfin and arc). Only a very few do not, and it is much easier to cater to those rather than all the others.
Actual use of the option will come in followup patches.
--- arch/Config.in | 6 ++++++ toolchain/Config.in | 1 + 2 files changed, 7 insertions(+)
arch/Config.in +6 -0
@@ -250,6 +250,12 @@ config BR2_xtensa endchoice +# For some architectures or specific cores, our internal toolchain +# backend is not suitable (like, missing support in upstream gcc, or +# no ChipCo fork exists...) +config BR2_ARCH_NO_INTERNAL_BACKEND + bool + # The following string values are defined by the individual # Config.in.$ARCH files config BR2_ARCH
toolchain/Config.in +1 -0
@@ -43,6 +43,7 @@ choice config BR2_TOOLCHAIN_BUILDROOT bool "Buildroot toolchain" select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS + depends on !BR2_ARCH_NO_INTERNAL_BACKEND depends on !BR2_bf606 depends on !BR2_bf607 depends on !BR2_bf608
Signature · 1 line
2.11.0
PATCH 1/4 arch: add option to disable internal toolchain backend
Hello,
Thanks for working on this!
arch/Config.in config BR2_xtensa · line 257
Quoted 5 lines · Yann E. MORIN
arch/Config.in +5
-0+# For some architectures or specific cores, our internal toolchain +# backend is not suitable (like, missing support in upstream gcc, or +# no ChipCo fork exists...) +config BR2_ARCH_NO_INTERNAL_BACKEND + bool
I'm not a big fan of the option name. What about:
config BR2_ARCH_HAS_TOOLCHAIN_BUILDROOT
bool
default y if !BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT
config BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT
bool
So, arches can select BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT, and else we can "depends on BR2_ARCH_HAS_TOOLCHAIN_BUILDROOT".
toolchain/Config.in choice · line 49
Quoted 12 lines
toolchain/Config.in +1
-0@@ -43,6 +43,7 @@ choice config BR2_TOOLCHAIN_BUILDROOT bool "Buildroot toolchain" select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS + depends on !BR2_ARCH_NO_INTERNAL_BACKEND depends on !BR2_bf606 depends on !BR2_bf607 depends on !BR2_bf608
Now that I think of it: we have dropped the Blackfin ADI external toolchain. Therefore, we currently have no in-tree solution to use/test bf606, bf607, bf608, etc. Perhaps we should drop them instead ?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 1/4 arch: add option to disable internal toolchain backend
Thomas, All,
On 2017-09-02 21:47 +0200, Thomas Petazzoni spake thusly:
Quoted 8 lines · Yann E. MORIN
arch/Config.in config BR2_xtensa · line 257
Quoted 5 lines
arch/Config.in +5
-0+# For some architectures or specific cores, our internal toolchain +# backend is not suitable (like, missing support in upstream gcc, or +# no ChipCo fork exists...) +config BR2_ARCH_NO_INTERNAL_BACKEND + boolI'm not a big fan of the option name. What about:
Oh, neither am I, neither am I. You know well that I am very bad at finding good names. ;-)
Quoted 9 lines
config
BR2_ARCH_HAS_TOOLCHAIN_BUILDROOT
bool
default y if !BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOTconfig
BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT
boolSo, arches can select
BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT, and else we can "depends onBR2_ARCH_HAS_TOOLCHAIN_BUILDROOT".
I also thought about doing so, yes, but is it really necessary to introduce two blind options just to have a positive logic in the only location we need it?
Quoted 8 lines
Quoted 8 lines
toolchain/Config.in +0
-0@@ -43,6 +43,7 @@ choice config BR2_TOOLCHAIN_BUILDROOT bool "Buildroot toolchain" select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS
Quoted 8 lines
toolchain/Config.in choice · line 49
Quoted 4 lines
toolchain/Config.in +1
-0+ depends on !BR2_ARCH_NO_INTERNAL_BACKEND depends on !BR2_bf606 depends on !BR2_bf607 depends on !BR2_bf608Now that I think of it: we have dropped the Blackfin ADI external toolchain. Therefore, we currently have no in-tree solution to use/test bf606, bf607, bf608, etc. Perhaps we should drop them instead ?
As already said: I don;t care about bfin, so I'm fine with dropping those bfin cores. But we'd still need BR2_ARCH_HAS_TOOLCHAIN_BUILDROOT and BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT for the rest, no?
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/4 arch: add option to disable internal toolchain backend
Hello,
Quoted 4 lines · Yann E. MORIN
Quoted 1 line
I'm not a big fan of the option name. What about:
Oh, neither am I, neither am I. You know well that I am very bad at finding good names. ;-)
No problem, that's what reviews are made for!
Quoted 6 lines
Quoted 2 lines
So, arches can select
BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT, and else we can "depends onBR2_ARCH_HAS_TOOLCHAIN_BUILDROOT".I also thought about doing so, yes, but is it really necessary to introduce two blind options just to have a positive logic in the only location we need it?
Yeah, I also thought about this. It's true that the positive symbol is going to be used only in one place, and it's the negative symbol (the one being selected) that will be used in most places.
So perhaps you're right, and having both hidden booleans is not that useful.
Quoted 7 lines
Quoted 3 lines
Now that I think of it: we have dropped the Blackfin ADI external toolchain. Therefore, we currently have no in-tree solution to use/test bf606, bf607, bf608, etc. Perhaps we should drop them instead ?
As already said: I don;t care about bfin, so I'm fine with dropping those bfin cores. But we'd still need
BR2_ARCH_HAS_TOOLCHAIN_BUILDROOTandBR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOTfor the rest, no?
Yes, we would still need them. I'm not at all saying that your patch series is not useful, I'm just saying that for Blackfin, dropping support for those cores is better :)
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 2/4 arch/csky: internal backend not suitable
In reply to Yann E. MORINUpstream gcc does not have support for C-Sky, and we do not have a vendor tree for it either (yet?).
Use the newly-introduced symbol to state so, rather than have the exclusion in the toolchain choice.
--- arch/Config.in | 1 + toolchain/Config.in | 1 - 2 files changed, 1 insertion(+), 1 deletion(-)
arch/Config.in +1 -0
@@ -87,6 +87,7 @@ config BR2_bfin config BR2_csky bool "csky" + select BR2_ARCH_NO_INTERNAL_BACKEND select BR2_ARCH_HAS_MMU_MANDATORY help csky is processor IP from china.
toolchain/Config.in +0 -1
@@ -48,7 +48,6 @@ config BR2_TOOLCHAIN_BUILDROOT depends on !BR2_bf607 depends on !BR2_bf608 depends on !BR2_bf609 - depends on !BR2_csky depends on !BR2_mips_m6250 depends on !BR2_mips_p6600
Signature · 1 line
2.11.0
PATCH 3/4 arch/bfin: internal backend not suitable for some cores
In reply to Yann E. MORINSome cores are not supported by upstream gcc.
Use the newly-introduced symbol to state so, rather than have the exclusion in the toolchain choice.
--- arch/Config.in.bfin | 4 ++++ toolchain/Config.in | 4 ---- 2 files changed, 4 insertions(+), 4 deletions(-)
arch/Config.in.bfin +4 -0
@@ -6,12 +6,16 @@ choice Specify target CPU config BR2_bf606 bool "bf606" + select BR2_ARCH_NOT_UPSTREAM_GCC config BR2_bf607 bool "bf607" + select BR2_ARCH_NOT_UPSTREAM_GCC config BR2_bf608 bool "bf608" + select BR2_ARCH_NOT_UPSTREAM_GCC config BR2_bf609 bool "bf609" + select BR2_ARCH_NOT_UPSTREAM_GCC config BR2_bf512 bool "bf512" config BR2_bf514
toolchain/Config.in +0 -4
@@ -44,10 +44,6 @@ config BR2_TOOLCHAIN_BUILDROOT bool "Buildroot toolchain" select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS depends on !BR2_ARCH_NO_INTERNAL_BACKEND - depends on !BR2_bf606 - depends on !BR2_bf607 - depends on !BR2_bf608 - depends on !BR2_bf609 depends on !BR2_mips_m6250 depends on !BR2_mips_p6600
Signature · 1 line
2.11.0
PATCH 3/4 arch/bfin: internal backend not suitable for some cores
Hello,
arch/Config.in.bfin choice · line 9
Quoted 9 lines · Yann E. MORIN
arch/Config.in.bfin +1
-0@@ -6,12 +6,16 @@ choice Specify target CPU config BR2_bf606 bool "bf606" + select BR2_ARCH_NOT_UPSTREAM_GCC
Where is this symbol introduced?
Seems like there is some issue in your patch series.
Also, as said in my review of PATCH 1/4, perhaps we should simply drop those Blackfin variants ?
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
PATCH 3/4 arch/bfin: internal backend not suitable for some cores
Thomas, All,
On 2017-09-02 21:48 +0200, Thomas Petazzoni spake thusly:
Quoted 11 lines · Yann E. MORIN
arch/Config.in.bfin choice · line 9
Quoted 9 lines
arch/Config.in.bfin +1
-0@@ -6,12 +6,16 @@ choice Specify target CPU config BR2_bf606 bool "bf606" + select BR2_ARCH_NOT_UPSTREAM_GCCWhere is this symbol introduced?
Grr... Bad rebase... I changed the name at the last minute, and there was a conflict. Sigh...
Quoted 4 lines
Seems like there is some issue in your patch series.
Also, as said in my review of PATCH 1/4, perhaps we should simply drop those Blackfin variants ?
Well, I personally don't care about bfin, so I'm also fine with removing the support for those cores.
That being said, we still need the feature, if any thing for consistency.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 4/4 arch/mips: internal backend not suitable for some cores
In reply to Yann E. MORINSome cores are not supported by upstream gcc.
Use the newly-introduced symbol to state so, rather than have the exclusion in the toolchain choice.
--- arch/Config.in.mips | 2 ++ toolchain/Config.in | 2 -- 2 files changed, 2 insertions(+), 2 deletions(-)
arch/Config.in.mips +2 -0
@@ -61,6 +61,7 @@ config BR2_mips_m5150 config BR2_mips_m6250 bool "M6250" depends on !BR2_ARCH_IS_64 + select BR2_ARCH_NOT_UPSTREAM_GCC select BR2_MIPS_CPU_MIPS32R6 config BR2_mips_p5600 bool "P5600"
@@ -103,6 +104,7 @@ config BR2_mips_i6400 config BR2_mips_p6600 bool "P6600" depends on BR2_ARCH_IS_64 + select BR2_ARCH_NOT_UPSTREAM_GCC select BR2_MIPS_CPU_MIPS64R6 endchoice
toolchain/Config.in +0 -2
@@ -44,8 +44,6 @@ config BR2_TOOLCHAIN_BUILDROOT bool "Buildroot toolchain" select BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS depends on !BR2_ARCH_NO_INTERNAL_BACKEND - depends on !BR2_mips_m6250 - depends on !BR2_mips_p6600 config BR2_TOOLCHAIN_EXTERNAL bool "External toolchain"
Signature · 1 line
2.11.0