[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[Masahiro Yamada]

Use the library code in the U-Boot source tree so we do not depend
on specific tool-chains.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
---

 arch/arm/Kconfig                        | 3 +++
 arch/arm/cpu/armv7/tegra-common/Kconfig | 3 ---
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 986b4c5..4d73530 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -51,6 +51,9 @@ config SYS_CPU
         default "sa1100" if CPU_SA1100
 	default "armv8" if ARM64
 
+config USE_PRIVATE_LIBGCC
+	default y
+
 config SEMIHOSTING
 	bool "support boot from semihosting"
 	help
diff --git a/arch/arm/cpu/armv7/tegra-common/Kconfig b/arch/arm/cpu/armv7/tegra-common/Kconfig
index 1446452..a5ab872 100644
--- a/arch/arm/cpu/armv7/tegra-common/Kconfig
+++ b/arch/arm/cpu/armv7/tegra-common/Kconfig
@@ -17,9 +17,6 @@ config TEGRA124
 
 endchoice
 
-config USE_PRIVATE_LIBGCC
-	default y if SPL_BUILD
-
 source "arch/arm/cpu/armv7/tegra20/Kconfig"
 source "arch/arm/cpu/armv7/tegra30/Kconfig"
 source "arch/arm/cpu/armv7/tegra114/Kconfig"
-- 
1.9.1

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[Albert ARIBAUD]

Hello Masahiro,

Your patch clashes with Pavel's already committed
break-if-private-libgcc-and-thumb, causing many boards to fail building.

I am putting your patch in 'under review' state until I can have a look
at what happens with private libgcc and thumb.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[Albert ARIBAUD]

On Thu, 16 Apr 2015 11:21:44 +0200, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hello Masahiro,
> 
> Your patch clashes with Pavel's already committed
> break-if-private-libgcc-and-thumb, causing many boards to fail building.
> 
> I am putting your patch in 'under review' state until I can have a look
> at what happens with private libgcc and thumb.

Hmm, even with the libgcc+thumb thing fixed, this patch still causes
quite a few target to fail:

- without the patch, buildman yields 503 1 12 / 516.
- With the patch, buildman yields 488 1 27 / 516.

Of these, 10 are aarch64 boards which now try to build a private libgcc
with some hardwired 32-bit mnemonics :

| arch/arm/lib/_ashldi3.S:21: Error: operand 1 should be an integer
register -- `subs r3,r2,#32' | arch/arm/lib/_ashldi3.S:22: Error: unknown mnemonic `rsb' -- `rsb ip,r2,#32' 
| arch/arm/lib/_ashldi3.S:23: Error: unknown mnemonic `movmi' -- `movmi r1,r1,lsl r2' 
| arch/arm/lib/_ashldi3.S:24: Error: unknown mnemonic `movpl' -- `movpl r1,r0,lsl r3' 
| arch/arm/lib/_ashldi3.S:25: Error: unknown mnemonic `orrmi' -- `orrmi r1,r1,r0,lsr ip' 
| arch/arm/lib/_ashldi3.S:26: Error: operand 1 should be an integer register -- `mov r0,r0,lsl r2' 
| arch/arm/lib/_ashldi3.S:27: Error: operand 1 should be an integer register -- `mov pc,lr' 

This should be fairly easy to fix by
 defaulting CONFIG_USE_PRIVATE_LIBGCC to 

The other 5 failures are snow, smdk5250, peach-pi, smdk5420, and
peach-pit, all of which show the same error:

> arch/arm/lib/lib.a(div0.o): In function `__div0': 
> arch/arm/lib/div0.c:13: undefined reference to `hang' 
> make[2]: *** [spl/u-boot-spl] Error 1 
> make[1]: *** [spl/u-boot-spl] Error 2 

That one is be a dependency on hang(). This function... hangs out... in
lib/hang.c, which according to lib/Makefile should be included in any
build, SPL or otherwise; but it appears lib/ is not built at all for
SPL, at least for these five targets.

Masahiro, can you have a look at e.g. snow (arm) and ls2085ardb
(aarch64) and see if you can update your patch to make sure these two
targets build? The other 13 should follow then.

> Amicalement,
> -- 
> Albert.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[Albert ARIBAUD]

Note: this is when applying the patch above current u-boot-arm/master.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[Masahiro Yamada]

Hi Albert,


2015-07-02 6:21 GMT+09:00 Albert ARIBAUD <albert.u.boot@aribaud.net>:
> On Thu, 16 Apr 2015 11:21:44 +0200, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
>> Hello Masahiro,
>>
>> Your patch clashes with Pavel's already committed
>> break-if-private-libgcc-and-thumb, causing many boards to fail building.
>>
>> I am putting your patch in 'under review' state until I can have a look
>> at what happens with private libgcc and thumb.
>
> Hmm, even with the libgcc+thumb thing fixed, this patch still causes
> quite a few target to fail:
>
> - without the patch, buildman yields 503 1 12 / 516.
> - With the patch, buildman yields 488 1 27 / 516.
>
> Of these, 10 are aarch64 boards which now try to build a private libgcc
> with some hardwired 32-bit mnemonics :
>
> | arch/arm/lib/_ashldi3.S:21: Error: operand 1 should be an integer
> register -- `subs r3,r2,#32' | arch/arm/lib/_ashldi3.S:22: Error: unknown mnemonic `rsb' -- `rsb ip,r2,#32'
> | arch/arm/lib/_ashldi3.S:23: Error: unknown mnemonic `movmi' -- `movmi r1,r1,lsl r2'
> | arch/arm/lib/_ashldi3.S:24: Error: unknown mnemonic `movpl' -- `movpl r1,r0,lsl r3'
> | arch/arm/lib/_ashldi3.S:25: Error: unknown mnemonic `orrmi' -- `orrmi r1,r1,r0,lsr ip'
> | arch/arm/lib/_ashldi3.S:26: Error: operand 1 should be an integer register -- `mov r0,r0,lsl r2'
> | arch/arm/lib/_ashldi3.S:27: Error: operand 1 should be an integer register -- `mov pc,lr'
>
> This should be fairly easy to fix by
>  defaulting CONFIG_USE_PRIVATE_LIBGCC to
>
> The other 5 failures are snow, smdk5250, peach-pi, smdk5420, and
> peach-pit, all of which show the same error:
>
>> arch/arm/lib/lib.a(div0.o): In function `__div0':
>> arch/arm/lib/div0.c:13: undefined reference to `hang'
>> make[2]: *** [spl/u-boot-spl] Error 1
>> make[1]: *** [spl/u-boot-spl] Error 2
>
> That one is be a dependency on hang(). This function... hangs out... in
> lib/hang.c, which according to lib/Makefile should be included in any
> build, SPL or otherwise; but it appears lib/ is not built at all for
> SPL, at least for these five targets.
>
> Masahiro, can you have a look at e.g. snow (arm) and ls2085ardb
> (aarch64) and see if you can update your patch to make sure these two
> targets build? The other 13 should follow then.

OK.
I will take a look.




-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[Albert ARIBAUD]

Hello Masahiro,

On Thu, 2 Jul 2015 21:21:12 +0900, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Hi Albert,
> 
> 
> 2015-07-02 6:21 GMT+09:00 Albert ARIBAUD <albert.u.boot@aribaud.net>:
> > On Thu, 16 Apr 2015 11:21:44 +0200, Albert ARIBAUD
> > <albert.u.boot@aribaud.net> wrote:
> >> Hello Masahiro,
> >>
> >> Your patch clashes with Pavel's already committed
> >> break-if-private-libgcc-and-thumb, causing many boards to fail building.
> >>
> >> I am putting your patch in 'under review' state until I can have a look
> >> at what happens with private libgcc and thumb.
> >
> > Hmm, even with the libgcc+thumb thing fixed, this patch still causes
> > quite a few target to fail:
> >
> > - without the patch, buildman yields 503 1 12 / 516.
> > - With the patch, buildman yields 488 1 27 / 516.
> >
> > Of these, 10 are aarch64 boards which now try to build a private libgcc
> > with some hardwired 32-bit mnemonics :
> >
> > | arch/arm/lib/_ashldi3.S:21: Error: operand 1 should be an integer
> > register -- `subs r3,r2,#32' | arch/arm/lib/_ashldi3.S:22: Error: unknown mnemonic `rsb' -- `rsb ip,r2,#32'
> > | arch/arm/lib/_ashldi3.S:23: Error: unknown mnemonic `movmi' -- `movmi r1,r1,lsl r2'
> > | arch/arm/lib/_ashldi3.S:24: Error: unknown mnemonic `movpl' -- `movpl r1,r0,lsl r3'
> > | arch/arm/lib/_ashldi3.S:25: Error: unknown mnemonic `orrmi' -- `orrmi r1,r1,r0,lsr ip'
> > | arch/arm/lib/_ashldi3.S:26: Error: operand 1 should be an integer register -- `mov r0,r0,lsl r2'
> > | arch/arm/lib/_ashldi3.S:27: Error: operand 1 should be an integer register -- `mov pc,lr'
> >
> > This should be fairly easy to fix by
> >  defaulting CONFIG_USE_PRIVATE_LIBGCC to
> >
> > The other 5 failures are snow, smdk5250, peach-pi, smdk5420, and
> > peach-pit, all of which show the same error:
> >
> >> arch/arm/lib/lib.a(div0.o): In function `__div0':
> >> arch/arm/lib/div0.c:13: undefined reference to `hang'
> >> make[2]: *** [spl/u-boot-spl] Error 1
> >> make[1]: *** [spl/u-boot-spl] Error 2
> >
> > That one is be a dependency on hang(). This function... hangs out... in
> > lib/hang.c, which according to lib/Makefile should be included in any
> > build, SPL or otherwise; but it appears lib/ is not built at all for
> > SPL, at least for these five targets.
> >
> > Masahiro, can you have a look at e.g. snow (arm) and ls2085ardb
> > (aarch64) and see if you can update your patch to make sure these two
> > targets build? The other 13 should follow then.
> 
> OK.
> I will take a look.

Ok -- don't rush, though. Seeing as there are contrary opinions on
whether we should use a private libgcc or not, I won't decide on
committing the patch right away.

> -- 
> Best Regards
> Masahiro Yamada

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[Masahiro Yamada]

2015-07-02 21:43 GMT+09:00 Albert ARIBAUD <albert.u.boot@aribaud.net>:
> Hello Masahiro,
>
> On Thu, 2 Jul 2015 21:21:12 +0900, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Hi Albert,
>>
>>
>> 2015-07-02 6:21 GMT+09:00 Albert ARIBAUD <albert.u.boot@aribaud.net>:
>> > On Thu, 16 Apr 2015 11:21:44 +0200, Albert ARIBAUD
>> > <albert.u.boot@aribaud.net> wrote:
>> >> Hello Masahiro,
>> >>
>> >> Your patch clashes with Pavel's already committed
>> >> break-if-private-libgcc-and-thumb, causing many boards to fail building.
>> >>
>> >> I am putting your patch in 'under review' state until I can have a look
>> >> at what happens with private libgcc and thumb.
>> >
>> > Hmm, even with the libgcc+thumb thing fixed, this patch still causes
>> > quite a few target to fail:
>> >
>> > - without the patch, buildman yields 503 1 12 / 516.
>> > - With the patch, buildman yields 488 1 27 / 516.
>> >
>> > Of these, 10 are aarch64 boards which now try to build a private libgcc
>> > with some hardwired 32-bit mnemonics :
>> >
>> > | arch/arm/lib/_ashldi3.S:21: Error: operand 1 should be an integer
>> > register -- `subs r3,r2,#32' | arch/arm/lib/_ashldi3.S:22: Error: unknown mnemonic `rsb' -- `rsb ip,r2,#32'
>> > | arch/arm/lib/_ashldi3.S:23: Error: unknown mnemonic `movmi' -- `movmi r1,r1,lsl r2'
>> > | arch/arm/lib/_ashldi3.S:24: Error: unknown mnemonic `movpl' -- `movpl r1,r0,lsl r3'
>> > | arch/arm/lib/_ashldi3.S:25: Error: unknown mnemonic `orrmi' -- `orrmi r1,r1,r0,lsr ip'
>> > | arch/arm/lib/_ashldi3.S:26: Error: operand 1 should be an integer register -- `mov r0,r0,lsl r2'
>> > | arch/arm/lib/_ashldi3.S:27: Error: operand 1 should be an integer register -- `mov pc,lr'
>> >
>> > This should be fairly easy to fix by
>> >  defaulting CONFIG_USE_PRIVATE_LIBGCC to
>> >
>> > The other 5 failures are snow, smdk5250, peach-pi, smdk5420, and
>> > peach-pit, all of which show the same error:
>> >
>> >> arch/arm/lib/lib.a(div0.o): In function `__div0':
>> >> arch/arm/lib/div0.c:13: undefined reference to `hang'
>> >> make[2]: *** [spl/u-boot-spl] Error 1
>> >> make[1]: *** [spl/u-boot-spl] Error 2
>> >
>> > That one is be a dependency on hang(). This function... hangs out... in
>> > lib/hang.c, which according to lib/Makefile should be included in any
>> > build, SPL or otherwise; but it appears lib/ is not built at all for
>> > SPL, at least for these five targets.
>> >
>> > Masahiro, can you have a look at e.g. snow (arm) and ls2085ardb
>> > (aarch64) and see if you can update your patch to make sure these two
>> > targets build? The other 13 should follow then.
>>
>> OK.
>> I will take a look.
>
> Ok -- don't rush, though. Seeing as there are contrary opinions on
> whether we should use a private libgcc or not, I won't decide on
> committing the patch right away.

OK.

If you think we should take our time for this discussion,
will you send a pull-request with currently applied change sets?
The 2015.07 will be released in 10 days.




-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default

[Albert ARIBAUD]

Hello Masahiro,

On Thu, 2 Jul 2015 21:54:44 +0900, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> 2015-07-02 21:43 GMT+09:00 Albert ARIBAUD <albert.u.boot@aribaud.net>:

> If you think we should take our time for this discussion,
> will you send a pull-request with currently applied change sets?
> The 2015.07 will be released in 10 days.

I am currently going through my todo precisely in order to send a PR. :)

> -- 
> Best Regards
> Masahiro Yamada

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Albert ARIBAUD]

On Thu, 16 Apr 2015 11:21:44 +0200, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hello Masahiro,
> 
> Your patch clashes with Pavel's already committed
> break-if-private-libgcc-and-thumb, causing many boards to fail building.
> 
> I am putting your patch in 'under review' state until I can have a look
> at what happens with private libgcc and thumb.

Hmm, even with the libgcc+thumb thing fixed, this patch still causes
quite a few target to fail:

- without the patch, buildman yields 503 1 12 / 516.
- With the patch, buildman yields 488 1 27 / 516.

Of these, 10 are aarch64 boards which now try to build a private libgcc
with some hardwired 32-bit mnemonics :

| arch/arm/lib/_ashldi3.S:21: Error: operand 1 should be an integer
register -- `subs r3,r2,#32' | arch/arm/lib/_ashldi3.S:22: Error:
unknown mnemonic `rsb' -- `rsb ip,r2,#32' | arch/arm/lib/_ashldi3.S:23:
Error: unknown mnemonic `movmi' -- `movmi r1,r1,lsl r2' |
arch/arm/lib/_ashldi3.S:24: Error: unknown mnemonic `movpl' -- `movpl
r1,r0,lsl r3' | arch/arm/lib/_ashldi3.S:25: Error: unknown mnemonic
`orrmi' -- `orrmi r1,r1,r0,lsr ip' | arch/arm/lib/_ashldi3.S:26: Error:
operand 1 should be an integer register -- `mov r0,r0,lsl r2' |
arch/arm/lib/_ashldi3.S:27: Error: operand 1 should be an integer
register -- `mov pc,lr' 

This should be fairly easy to fix by
 defaulting CONFIG_USE_PRIVATE_LIBGCC to 

The other 5 failures are snow, smdk5250, peach-pi, smdk5420, and
peach-pit, all of which show the same error:

> arch/arm/lib/lib.a(div0.o): In function `__div0': 
> arch/arm/lib/div0.c:13: undefined reference to `hang' 
> make[2]: *** [spl/u-boot-spl] Error 1 
> make[1]: *** [spl/u-boot-spl] Error 2 

That one is be a dependency on hang(). This function... hangs out... in
lib/hang.c, which according to lib/Makefile should be included in any
build, SPL or otherwise; but it appears lib/ is not built at all for
SPL, at least for these five targets.

Masahiro, can you have a look at e.g. snow (arm) and ls2085ardb
(aarch64) and see if you can update your patch to make sure these two
targets build? The other 13 should follow then.

Note: this is when applying the patch above current u-boot-arm/master.

> Amicalement,
> -- 
> Albert.

Amicalement,
-- 
Albert.
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Wolfgang Denk]

Dear Albert,

In message <20150701234229.705fe4ce@lilith> you wrote:
> On Thu, 16 Apr 2015 11:21:44 +0200, Albert ARIBAUD
> <albert.u.boot@aribaud.net> wrote:
> > Hello Masahiro,
> > 
> > Your patch clashes with Pavel's already committed
> > break-if-private-libgcc-and-thumb, causing many boards to fail building.
> > 
> > I am putting your patch in 'under review' state until I can have a look
> > at what happens with private libgcc and thumb.
> 
> Hmm, even with the libgcc+thumb thing fixed, this patch still causes
> quite a few target to fail:
> 
> - without the patch, buildman yields 503 1 12 / 516.
> - With the patch, buildman yields 488 1 27 / 516.
> 
> Of these, 10 are aarch64 boards which now try to build a private libgcc
> with some hardwired 32-bit mnemonics :

Actually I think it is inherently wrong to enable
CONFIG_USE_PRIVATE_LIBGCC by default.

This option is intended as a workaround for broken toolchains, until
these get fixed.  By enabling this by default, we miss do not notice
the problems our tool chain has, and therefore these never get fixed,
i. e. brokenness grows.  This cannot be good.

CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
never ever a default setting.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Cogito cogito ergo cogito sum - "I think that I  think,  therefore  I
think that I am."          - Ambrose Bierce, "The Devil's Dictionary"

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Albert ARIBAUD]

Hello Wolfgang,

On Wed, 01 Jul 2015 23:50:17 +0200, Wolfgang Denk <wd@denx.de> wrote:

> Actually I think it is inherently wrong to enable
> CONFIG_USE_PRIVATE_LIBGCC by default.
> 
> This option is intended as a workaround for broken toolchains, until
> these get fixed.  By enabling this by default, we miss do not notice
> the problems our tool chain has, and therefore these never get fixed,
> i. e. brokenness grows.  This cannot be good.
> 
> CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
> never ever a default setting.

Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
we allow it by default for all architectures, or we forbid it by
default for all architectures, but I don't like the idea of a
heterogeneous per-arch default setting.

> Best regards,
> 
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Daniel Schwierzeck]

Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
> Hello Wolfgang,
> 
> On Wed, 01 Jul 2015 23:50:17 +0200, Wolfgang Denk <wd@denx.de> wrote:
> 
>> Actually I think it is inherently wrong to enable
>> CONFIG_USE_PRIVATE_LIBGCC by default.
>>
>> This option is intended as a workaround for broken toolchains, until
>> these get fixed.  By enabling this by default, we miss do not notice
>> the problems our tool chain has, and therefore these never get fixed,
>> i. e. brokenness grows.  This cannot be good.
>>
>> CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
>> never ever a default setting.
> 
> Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
> enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
> we allow it by default for all architectures, or we forbid it by
> default for all architectures, but I don't like the idea of a
> heterogeneous per-arch default setting.
> 

CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports
a private libgcc, then it should always use it. I think for U-Boot it is
better and safer to have all code under control instead of pulling in
external code from toolchains which are often somehow broken.

Speaking for MIPS we have boards with all combinations of Big
Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc
binary for each FPU variant, but almost no toolchain supports this. Thus
you need different toolchains for different boards. This is a PITA for
users or developers who want to use buildman. Always using
CONFIG_USE_PRIVATE_LIBGCC=yes was the only painless way so far. That is
why we chose to enable CONFIG_USE_PRIVATE_LIBGCC by default.

BTW: Linux kernel or Barebox always use a private libgcc.

-- 
- Daniel

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Albert ARIBAUD]

Hello Daniel,

(not sure how in my previous reply I managed to drop Masahiro off the
discussion; fixing that, and apologies)

On Thu, 02 Jul 2015 01:39:17 +0200, Daniel Schwierzeck
<daniel.schwierzeck@gmail.com> wrote:
> 
> 
> Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
> > Hello Wolfgang,
> > 
> > On Wed, 01 Jul 2015 23:50:17 +0200, Wolfgang Denk <wd@denx.de> wrote:
> > 
> >> Actually I think it is inherently wrong to enable
> >> CONFIG_USE_PRIVATE_LIBGCC by default.
> >>
> >> This option is intended as a workaround for broken toolchains, until
> >> these get fixed.  By enabling this by default, we miss do not notice
> >> the problems our tool chain has, and therefore these never get fixed,
> >> i. e. brokenness grows.  This cannot be good.
> >>
> >> CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
> >> never ever a default setting.
> > 
> > Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
> > enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
> > we allow it by default for all architectures, or we forbid it by
> > default for all architectures, but I don't like the idea of a
> > heterogeneous per-arch default setting.
> > 
> 
> CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports
> a private libgcc, then it should always use it. I think for U-Boot it is
> better and safer to have all code under control instead of pulling in
> external code from toolchains which are often somehow broken.
> 
> Speaking for MIPS we have boards with all combinations of Big
> Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc
> binary for each FPU variant, but almost no toolchain supports this. Thus
> you need different toolchains for different boards. This is a PITA for
> users or developers who want to use buildman. Always using
> CONFIG_USE_PRIVATE_LIBGCC=yes was the only painless way so far. That is
> why we chose to enable CONFIG_USE_PRIVATE_LIBGCC by default.
> 
> BTW: Linux kernel or Barebox always use a private libgcc.

Seems like there is room for debate on the topic, then, which I'll
start in another topic.

From a short-term perspective, I will defer the present patch because
applying it makes U-Boot support fifteen less targets than not applying
it, which I think we can agree goes in the cons list of both approaches.

> -- 
> - Daniel

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Wolfgang Denk]

Dear Daniel,

In message <55947A25.5020702@gmail.com> you wrote:
> 
> CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports
> a private libgcc, then it should always use it. I think for U-Boot it is
> better and safer to have all code under control instead of pulling in
> external code from toolchains which are often somehow broken.

This is the wrong approach.  If a tool is broken, it should be
reported, and fixed.

> Speaking for MIPS we have boards with all combinations of Big
> Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc
> binary for each FPU variant, but almost no toolchain supports this. Thus

Why would that be the case?  We do not use any floating point stuff in
U-Boot...


I agree that there is the endianess issue - MIPS is currently the
only architecture (I am aware of) that supports both BE and LE con-
figurations.  But this is a tool chain issue!  You will need support
from the tool chain not only for U-Boot (and the kernel), but also for
user space.  If your tool chain is nbroken, it needs fixing.

> BTW: Linux kernel or Barebox always use a private libgcc.

And what do you do about user space with such a broken tool chain?

It does not help to paper over problems.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Save yourself!  Reboot in 5 seconds!

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Masahiro Yamada]

2015-07-02 16:39 GMT+09:00 Wolfgang Denk <wd@denx.de>:
> Dear Daniel,
>
> In message <55947A25.5020702@gmail.com> you wrote:
>>
>> CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports
>> a private libgcc, then it should always use it. I think for U-Boot it is
>> better and safer to have all code under control instead of pulling in
>> external code from toolchains which are often somehow broken.
>
> This is the wrong approach.  If a tool is broken, it should be
> reported, and fixed.
>
>> Speaking for MIPS we have boards with all combinations of Big
>> Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc
>> binary for each FPU variant, but almost no toolchain supports this. Thus
>
> Why would that be the case?  We do not use any floating point stuff in
> U-Boot...
>
>
> I agree that there is the endianess issue - MIPS is currently the
> only architecture (I am aware of) that supports both BE and LE con-
> figurations.  But this is a tool chain issue!  You will need support
> from the tool chain not only for U-Boot (and the kernel), but also for
> user space.  If your tool chain is nbroken, it needs fixing.
>
>> BTW: Linux kernel or Barebox always use a private libgcc.
>
> And what do you do about user space with such a broken tool chain?
>
> It does not help to paper over problems.
>

Some people might want to build only U-boot from source code
and install a pre-built distribution, maybe ?





-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Wolfgang Denk]

Dear Masahiro,

In message <CAK7LNATyqVrRn_3rPtsotF5JqF16rxqV0Z9LYCUjwzB4A7AFMw@mail.gmail.com> you wrote:
>
> > And what do you do about user space with such a broken tool chain?
> >
> > It does not help to paper over problems.
> 
> Some people might want to build only U-boot from source code
> and install a pre-built distribution, maybe ?

Yes, of course.  And they would be perfectly happy if they had a
_working_ tool chain which supports this.

But some do not, and instead of telling the makers of the ool chain
about our needs and wishes, each and every project works around the
issues, providing copies and copis of the same code, which is isolated
and not centrally maintained, and thus usually of poorer quality than
what you can find in recent tool chain versions.

The optimal way to fix a problem is to have it fixed at the root.

CONFIG_USE_PRIVATE_LIBGCC is a workaround, but enabling it by default
means freezing the status quo: upstream tools will never get fixed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The price of success is hard work, dedication to the job at hand, and
the determination that whether we win or lose, we  have  applied  the
best of ourselves to the task at hand.               - Vince Lombardi

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Daniel Schwierzeck]

Am 02.07.2015 um 09:39 schrieb Wolfgang Denk:
> Dear Daniel,
> 
> In message <55947A25.5020702@gmail.com> you wrote:
>>
>> CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports
>> a private libgcc, then it should always use it. I think for U-Boot it is
>> better and safer to have all code under control instead of pulling in
>> external code from toolchains which are often somehow broken.
> 
> This is the wrong approach.  If a tool is broken, it should be
> reported, and fixed.
> 
>> Speaking for MIPS we have boards with all combinations of Big
>> Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc
>> binary for each FPU variant, but almost no toolchain supports this. Thus
> 
> Why would that be the case?  We do not use any floating point stuff in
> U-Boot...

the toolchain need to provide a binary libgcc.a for each combination of
Endianess and FPU variant otherwise you will get errors on linking
libgcc.a to U-Boot. U-Boot needs at least BE/SoftFloat and LE/SoftFloat.
But you only have multiple libgcc.a binaries in a dedicated multilib
toolchain. AFAIK only CodeSourcery and Yocto-based ELDK supports this.
Other pre-built toolchains usually support only one combination.
Furthermore toolchains like Yocto or kernel.org often use HardFloat by
default. For using buildman without CONFIG_USE_PRIVATE_LIBGCC you either
have to look for a suitable multilib toolchain or you have to fiddle
with multiple toolchains.

The simplest and safest way is to bundle the SoftFloat implementation of
the few GCC functions needed from libgcc in U-Boot. That code will be
compiled then in the correct Endianess dependend on the board config.

> 
> 
> I agree that there is the endianess issue - MIPS is currently the
> only architecture (I am aware of) that supports both BE and LE con-
> figurations.  But this is a tool chain issue!  You will need support
> from the tool chain not only for U-Boot (and the kernel), but also for
> user space.  If your tool chain is nbroken, it needs fixing.
> 
>> BTW: Linux kernel or Barebox always use a private libgcc.
> 
> And what do you do about user space with such a broken tool chain?
> 
> It does not help to paper over problems.
> 
> Best regards,
> 
> Wolfgang Denk
> 

if you only target a specific board with U-Boot, OS, Userspace then you
can choose a toolchain with the right combination of Endianess, FPU
variant and libc.

The problem only occurs with buildman or bare-metal toolchains. The
toolchains do not need to be broken.

-- 
- Daniel

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Wolfgang Denk]

Dear Daniel,

In message <559532A4.30900@gmail.com> you wrote:
> 
> > Why would that be the case?  We do not use any floating point stuff in
> > U-Boot...
> 
> the toolchain need to provide a binary libgcc.a for each combination of
> Endianess and FPU variant otherwise you will get errors on linking
> libgcc.a to U-Boot. U-Boot needs at least BE/SoftFloat and LE/SoftFloat.
> But you only have multiple libgcc.a binaries in a dedicated multilib
> toolchain. AFAIK only CodeSourcery and Yocto-based ELDK supports this.

I agree so far.

From here, different approaches are possible:

- silently accept our fate, and have myultiple projects all work aound
  the issues, copying libgcc code again and again, leaving many copies
  in usually ill-maintained state.
- tell the upstream folks about our needs and have them provide us
  with tools that actually can be used for our purposes.

The second approach may take longer, but in my opinion is still the
much better approahc.  CONFIG_USE_PRIVATE_LIBGCC is intended to be a
workaround until we get such improved tools from upstream, not as a
permanent solution - it does not solve the rpoblem, it just papers
over it.

> The simplest and safest way is to bundle the SoftFloat implementation of
> the few GCC functions needed from libgcc in U-Boot. That code will be
> compiled then in the correct Endianess dependend on the board config.

I read "simplest and safest way" as "quick and dirty hack".

> The problem only occurs with buildman or bare-metal toolchains. The
> toolchains do not need to be broken.

Hm... when I cannot use a tool for the intended purpose I tend to call
it broken, or at least unsuitable.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Today's robots are very primitive, capable of understanding  only  a
few  simple  instructions  such  as 'go left', 'go right', and 'build
car'."                                                  - John Sladek

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Masahiro Yamada]

2015-07-02 8:39 GMT+09:00 Daniel Schwierzeck <daniel.schwierzeck@gmail.com>:
>
>
> Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
>> Hello Wolfgang,
>>
>> On Wed, 01 Jul 2015 23:50:17 +0200, Wolfgang Denk <wd@denx.de> wrote:
>>
>>> Actually I think it is inherently wrong to enable
>>> CONFIG_USE_PRIVATE_LIBGCC by default.
>>>
>>> This option is intended as a workaround for broken toolchains, until
>>> these get fixed.  By enabling this by default, we miss do not notice
>>> the problems our tool chain has, and therefore these never get fixed,
>>> i. e. brokenness grows.  This cannot be good.
>>>
>>> CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
>>> never ever a default setting.
>>
>> Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
>> enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
>> we allow it by default for all architectures, or we forbid it by
>> default for all architectures, but I don't like the idea of a
>> heterogeneous per-arch default setting.
>>
>
> CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports
> a private libgcc, then it should always use it. I think for U-Boot it is
> better and safer to have all code under control instead of pulling in
> external code from toolchains which are often somehow broken.
>
> Speaking for MIPS we have boards with all combinations of Big
> Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc
> binary for each FPU variant, but almost no toolchain supports this. Thus
> you need different toolchains for different boards. This is a PITA for
> users or developers who want to use buildman. Always using
> CONFIG_USE_PRIVATE_LIBGCC=yes was the only painless way so far. That is
> why we chose to enable CONFIG_USE_PRIVATE_LIBGCC by default.
>
> BTW: Linux kernel or Barebox always use a private libgcc.
>


I agree with Daniel.

Instead of removing CONFIG_USE_PRIVATE_LIBGCC,
I think it is better to "select" it by Kconfig.

(And rename it to CONFIG_HAVE_PRIVATE_LIBGCC
in order to clearly indicate it is not a user-configurable
but forced configuration.)




-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Masahiro Yamada]

2015-07-02 21:18 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> 2015-07-02 8:39 GMT+09:00 Daniel Schwierzeck <daniel.schwierzeck@gmail.com>:
>>
>>
>> Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
>>> Hello Wolfgang,
>>>
>>> On Wed, 01 Jul 2015 23:50:17 +0200, Wolfgang Denk <wd@denx.de> wrote:
>>>
>>>> Actually I think it is inherently wrong to enable
>>>> CONFIG_USE_PRIVATE_LIBGCC by default.
>>>>
>>>> This option is intended as a workaround for broken toolchains, until
>>>> these get fixed.  By enabling this by default, we miss do not notice
>>>> the problems our tool chain has, and therefore these never get fixed,
>>>> i. e. brokenness grows.  This cannot be good.
>>>>
>>>> CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
>>>> never ever a default setting.
>>>
>>> Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
>>> enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
>>> we allow it by default for all architectures, or we forbid it by
>>> default for all architectures, but I don't like the idea of a
>>> heterogeneous per-arch default setting.
>>>
>>
>> CONFIG_USE_PRIVATE_LIBGCC should be removed. If an architecture supports
>> a private libgcc, then it should always use it. I think for U-Boot it is
>> better and safer to have all code under control instead of pulling in
>> external code from toolchains which are often somehow broken.
>>
>> Speaking for MIPS we have boards with all combinations of Big
>> Endian/Little Endian and Hard Float/Soft Float. You need an own libgcc
>> binary for each FPU variant, but almost no toolchain supports this. Thus
>> you need different toolchains for different boards. This is a PITA for
>> users or developers who want to use buildman. Always using
>> CONFIG_USE_PRIVATE_LIBGCC=yes was the only painless way so far. That is
>> why we chose to enable CONFIG_USE_PRIVATE_LIBGCC by default.
>>
>> BTW: Linux kernel or Barebox always use a private libgcc.
>>
>
>
> I agree with Daniel.
>
> Instead of removing CONFIG_USE_PRIVATE_LIBGCC,
> I think it is better to "select" it by Kconfig.
>
> (And rename it to CONFIG_HAVE_PRIVATE_LIBGCC
> in order to clearly indicate it is not a user-configurable
> but forced configuration.)

My bad.
Daniel, you are right.

We already have CONFIG_HAVE_PRIVATE_LIBGCC.
So, removing CONFIG_USE_PRIVATE_LIBGCC is OK.



-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Wolfgang Denk]

Dear Masahiro,

In message <CAK7LNASsNVNj-neDO_7XT0t8RZO-EsHdP+WQGLbffxBrpR3pPg@mail.gmail.com> you wrote:
>
> Instead of removing CONFIG_USE_PRIVATE_LIBGCC,
> I think it is better to "select" it by Kconfig.

I think CONFIG_USE_PRIVATE_LIBGCC should remain, and be selectable by
Kconfig (but only if CONFIG_HAVE_PRIVATE_LIBGCC is set, see below).

And my opinion is that CONFIG_USE_PRIVATE_LIBGCC should _not_ be set
by default.

> (And rename it to CONFIG_HAVE_PRIVATE_LIBGCC
> in order to clearly indicate it is not a user-configurable
> but forced configuration.)

No, that would be wrong.  "HAVE" means that the capability exists.
This does not include any statement if you actually use it or not.
"USE" means that you actuallyuse it (and makes only sense if "HAVE" is
set, as you cannot use what you don't have.

So "HAVE" and "USE" are two distinct properties.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Am besten betrachten Sie Fehlermeldungen als eine  Art  Psycho-Test,
mit  dem  herausgefunden  werden soll, wie belastbar Sie sind."
 - Dr. R. Wonneberger, Kompaktf?hrer LaTeX, Kap. 1.6: Fehlermeldungen

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Wolfgang Denk]

Dear Albert,

In message <20150702000427.562195b4@lilith> you wrote:
> 
> > CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
> > never ever a default setting.
> 
> Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
> enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
> we allow it by default for all architectures, or we forbid it by
> default for all architectures, but I don't like the idea of a
> heterogeneous per-arch default setting.

Agreed.  I'm really unhappy that I missed these commits (but I have to
admit that I don't look too closely at these architectures).

Adding Daniel and Nobuhiro to the address list.

Please correct me if I'm wrong:

- SH: Commit c3dd823 looks as if there was no strong reason for this
  change, it sounds more like "this works now, so let's do it
  always".

  Is this correct?  Then there would be no strong feelings to revert
  this commit?

- MIPS: Commit 7bfd5ee is more complicatred.  MIPS is one of the few
  architectures (the only one?) were we have both big endian and
  little endian configurations.  This is easy to support within a tool
  chain.  But do we really have MIPS boards that use hard-float? And
  if so, why would that be the case?  U-Boot should not contain any
  floating point code - if it does, this is an error that needs
  fixing.  As such, this should be a non-issue.

  I would expect that any somewhat recent tool chain is now able to
  support building of both BE and LE MIPS configurations - which are
  the ones that casue problems here?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Do not simplify the design of a program if a way can be found to make
it complex and wonderful.

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Masahiro Yamada]

Hi Wolfgang,


2015-07-02 16:34 GMT+09:00 Wolfgang Denk <wd@denx.de>:
> Dear Albert,
>
> In message <20150702000427.562195b4@lilith> you wrote:
>>
>> > CONFIG_USE_PRIVATE_LIBGCC should only be an emergency-opt-in, but
>> > never ever a default setting.
>>
>> Well then, should we not revisit commits c3dd823 and 7bfd5ee, which
>> enable CONFIG_USE_PRIVATE_LIBGCC for sh and mips respectively? Either
>> we allow it by default for all architectures, or we forbid it by
>> default for all architectures, but I don't like the idea of a
>> heterogeneous per-arch default setting.
>
> Agreed.  I'm really unhappy that I missed these commits (but I have to
> admit that I don't look too closely at these architectures).
>
> Adding Daniel and Nobuhiro to the address list.
>
> Please correct me if I'm wrong:
>
> - SH: Commit c3dd823 looks as if there was no strong reason for this
>   change, it sounds more like "this works now, so let's do it
>   always".
>
>   Is this correct?  Then there would be no strong feelings to revert
>   this commit?

No.

I turned on CONFIG_USE_PRIVATE_LIBGCC for SuperH
because more boards succeeded to build with the private library.


If I revert c3dd823, I get the following error on some boards
and with some toolchains.

/opt/crosstools/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-ld.bfd:
/opt/crosstools/sh4-gentoo-linux-gnu/libexec/gcc/sh4-gentoo-linux-gnu/4.7.1/../../../../lib/gcc/sh4-gentoo-linux-gnu/4.7.1/libgcc.a(_movmem.o):
compiled for a little endian system and target is big endian



> - MIPS: Commit 7bfd5ee is more complicatred.  MIPS is one of the few
>   architectures (the only one?) were we have both big endian and
>   little endian configurations.  This is easy to support within a tool
>   chain.  But do we really have MIPS boards that use hard-float? And
>   if so, why would that be the case?  U-Boot should not contain any
>   floating point code - if it does, this is an error that needs
>   fixing.  As such, this should be a non-issue.
>
>   I would expect that any somewhat recent tool chain is now able to
>   support building of both BE and LE MIPS configurations - which are
>   the ones that casue problems here?
>

In my understanding, SuperH is also dual-endian architecture.
So, I think the situation is similar to MIPS.

SH2 is fixed to big-endian, but SH3 and later support both big and little.


Nobuhiro - please correct me if I am wrong.


-- 
Best Regards
Masahiro Yamada

[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)

[Wolfgang Denk]

Dear Masahiro,

In message <CAK7LNARHZB0mquGQjF4UOS4ztBsC2V3-jddJaYvbxmNB+i=MoQ@mail.gmail.com> you wrote:
> 
> If I revert c3dd823, I get the following error on some boards
> and with some toolchains.
> 
> /opt/crosstools/sh4-gentoo-linux-gnu/bin/sh4-gentoo-linux-gnu-ld.bfd:
> /opt/crosstools/sh4-gentoo-linux-gnu/libexec/gcc/sh4-gentoo-linux-gnu/4.7.1/../../../../lib/gcc/sh4-gentoo-linux-gnu/4.7.1/libgcc.a(_movmem.o):
> compiled for a little endian system and target is big endian

So the cross tool chain does not support big endian systems.

> In my understanding, SuperH is also dual-endian architecture.
> So, I think the situation is similar to MIPS.
> 
> SH2 is fixed to big-endian, but SH3 and later support both big and little.

Thanks for pointing out.  I was not aware of this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Beware of programmers carrying screwdrivers."      - Chip Salzenberg