[U-Boot] [PATCH] ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
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"
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,
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,
Note: this is when applying the patch above current u-boot-arm/master.
Amicalement,
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.
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,
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.
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,
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,
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
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,
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.
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,
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
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 ?
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
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.
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
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.)
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.
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
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
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.
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
participants (5)
-
Albert ARIBAUD -
Daniel Schwierzeck -
Masahiro Yamada -
Masahiro Yamada -
Wolfgang Denk