[Buildroot] [PATCH 0/4] arch: not all have support in the internal backend

[Buildroot] [PATCH 0/4] arch: not all have support in the internal backend

[Yann E. MORIN]

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

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

[Buildroot] [PATCH 1/4] arch: add option to disable internal toolchain backend

[Yann E. MORIN]

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.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
 arch/Config.in      | 6 ++++++
 toolchain/Config.in | 1 +
 2 files changed, 7 insertions(+)

diff --git a/arch/Config.in b/arch/Config.in
index f385745e47..da893caf5a 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -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
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 584d053058..919757e558 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -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
-- 
2.11.0

[Buildroot] [PATCH 2/4] arch/csky: internal backend not suitable

[Yann E. MORIN]

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

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
 arch/Config.in      | 1 +
 toolchain/Config.in | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/Config.in b/arch/Config.in
index da893caf5a..ae9b084114 100644
--- a/arch/Config.in
+++ b/arch/Config.in
@@ -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.
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 919757e558..5e4ccb5baf 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -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
 
-- 
2.11.0

[Buildroot] [PATCH 3/4] arch/bfin: internal backend not suitable for some cores

[Yann E. MORIN]

Some cores are not supported by upstream gcc.

Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
 arch/Config.in.bfin | 4 ++++
 toolchain/Config.in | 4 ----
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/Config.in.bfin b/arch/Config.in.bfin
index 90e4ab97b0..8c1c80ad52 100644
--- a/arch/Config.in.bfin
+++ b/arch/Config.in.bfin
@@ -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
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 5e4ccb5baf..94cccea57e 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -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
 
-- 
2.11.0

[Buildroot] [PATCH 4/4] arch/mips: internal backend not suitable for some cores

[Yann E. MORIN]

Some cores are not supported by upstream gcc.

Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
 arch/Config.in.mips | 2 ++
 toolchain/Config.in | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/Config.in.mips b/arch/Config.in.mips
index 89e6effee9..0c4f63214e 100644
--- a/arch/Config.in.mips
+++ b/arch/Config.in.mips
@@ -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
 
diff --git a/toolchain/Config.in b/toolchain/Config.in
index 94cccea57e..06ea08fe66 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -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"
-- 
2.11.0

[Buildroot] [PATCH 1/4] arch: add option to disable internal toolchain backend

[Thomas Petazzoni]

Hello,

Thanks for working on this!

On Sat,  2 Sep 2017 21:38:49 +0200, Yann E. MORIN wrote:

> +# 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".

> diff --git a/toolchain/Config.in b/toolchain/Config.in
> index 584d053058..919757e558 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 3/4] arch/bfin: internal backend not suitable for some cores

[Thomas Petazzoni]

Hello,

On Sat,  2 Sep 2017 21:38:51 +0200, Yann E. MORIN wrote:

> diff --git a/arch/Config.in.bfin b/arch/Config.in.bfin
> index 90e4ab97b0..8c1c80ad52 100644
> --- a/arch/Config.in.bfin
> +++ b/arch/Config.in.bfin
> @@ -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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH 3/4] arch/bfin: internal backend not suitable for some cores

[Yann E. MORIN]

Thomas, All,

On 2017-09-02 21:48 +0200, Thomas Petazzoni spake thusly:
> On Sat,  2 Sep 2017 21:38:51 +0200, Yann E. MORIN wrote:
> > diff --git a/arch/Config.in.bfin b/arch/Config.in.bfin
> > index 90e4ab97b0..8c1c80ad52 100644
> > --- a/arch/Config.in.bfin
> > +++ b/arch/Config.in.bfin
> > @@ -6,12 +6,16 @@ choice
> >  	  Specify target CPU
> >  config BR2_bf606
> >  	bool "bf606"
> > +	select BR2_ARCH_NOT_UPSTREAM_GCC
> Where is this symbol introduced?

Grr... Bad rebase... I changed the name at the last minute, and there
was a conflict. Sigh...

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

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

[Buildroot] [PATCH 1/4] arch: add option to disable internal toolchain backend

[Yann E. MORIN]

Thomas, All,

On 2017-09-02 21:47 +0200, Thomas Petazzoni spake thusly:
> On Sat,  2 Sep 2017 21:38:49 +0200, Yann E. MORIN wrote:
> > +# 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:

Oh, neither am I, neither am I. You know well that I am very bad at
finding good names. ;-)

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

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?

> > diff --git a/toolchain/Config.in b/toolchain/Config.in
> > index 584d053058..919757e558 100644
> > --- a/toolchain/Config.in
> > +++ b/toolchain/Config.in
> > @@ -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 ?

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.

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

[Buildroot] [PATCH 1/4] arch: add option to disable internal toolchain backend

[Thomas Petazzoni]

Hello,

On Sat, 2 Sep 2017 22:10:10 +0200, Yann E. MORIN wrote:

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

> > So, arches can select BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT, and else
> > we can "depends on BR2_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.

> > 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_BUILDROOT
> and BR2_ARCH_HAS_NO_TOOLCHAIN_BUILDROOT for 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
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com