ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
Subsystems (2)
PATCH 1/1 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.
---
arch/arm/Kconfig | 3 +++ arch/arm/cpu/armv7/tegra-common/Kconfig | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-)
arch/arm/Kconfig +3 -0
@@ -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
arch/arm/cpu/armv7/tegra-common/Kconfig +0 -3
@@ -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"
Signature · 1 line
1.9.1
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
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,
Signature · 1 line
Albert.
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
Quoted 7 lines · 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.
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:
Quoted 4 lines
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.
Quoted 3 lines
Amicalement,
Signature · 1 line
Albert.
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
Note: this is when applying the patch above current u-boot-arm/master.
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
In reply to Albert ARIBAUDHi Albert,
2015-07-02 6:21 GMT+09:00 Albert ARIBAUD <[email protected]>:
Quoted 38 lines
Quoted 7 lines · 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.
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 mnemonicrsb' -- `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
defaultingCONFIG_USE_PRIVATE_LIBGCCtoThe other 5 failures are snow, smdk5250, peach-pi, smdk5420, and peach-pit, all of which show the same error:
Quoted 4 lines
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
Quoted 8 lines
That one is be a dependency on
hang(). This function... hangs out... inlib/hang.c, which according to lib/Makefile should be included in any build, SPL or otherwise; but it appearslib/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.
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
Hello Masahiro,
Quoted 47 lines · Masahiro Yamada
Hi Albert,
2015-07-02 6:21 GMT+09:00 Albert ARIBAUD <[email protected]>:
Quoted 43 lines
Quoted 7 lines · 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.
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 mnemonicrsb' -- `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
defaultingCONFIG_USE_PRIVATE_LIBGCCtoThe other 5 failures are snow, smdk5250, peach-pi, smdk5420, and peach-pit, all of which show the same error:
Quoted 4 lines
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 2That one is be a dependency on
hang(). This function... hangs out... inlib/hang.c, which according to lib/Makefile should be included in any build, SPL or otherwise; but it appearslib/is not built at all for SPL, at least for these five targets.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 3 lines
Signature · 2 lines
Best Regards Masahiro Yamada
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
2015-07-02 21:43 GMT+09:00 Albert ARIBAUD <[email protected]>:
Quoted 55 lines
Hello Masahiro,
Quoted 51 lines · Masahiro Yamada
Hi Albert,
2015-07-02 6:21 GMT+09:00 Albert ARIBAUD <[email protected]>:
Quoted 46 lines
Quoted 7 lines · 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.
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 mnemonicrsb' -- `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
defaultingCONFIG_USE_PRIVATE_LIBGCCtoThe other 5 failures are snow, smdk5250, peach-pi, smdk5420, and peach-pit, all of which show the same error:
Quoted 4 lines
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 2That one is be a dependency on
hang(). This function... hangs out... inlib/hang.c, which according to lib/Makefile should be included in any build, SPL or otherwise; but it appearslib/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.
Quoted 6 lines
Quoted 2 lines
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.
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default
Hello Masahiro,
Quoted 5 lines · Masahiro Yamada
2015-07-02 21:43 GMT+09:00 Albert ARIBAUD <[email protected]>:
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. :)
Quoted 3 lines
Signature · 2 lines
Best Regards Masahiro Yamada
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
In reply to Albert ARIBAUDQuoted 7 lines · 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.
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:
Quoted 4 lines
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.
Quoted 3 lines
Amicalement,
Signature · 1 line
Albert.
Amicalement,
Signature · 5 lines
Albert. _______________________________________________ U-Boot mailing list U-Boot at lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Dear Albert,
Quoted 10 lines · In message <20150701234229.705fe4ce@lilith> you wrote:
Quoted 7 lines · 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.
Quoted 8 lines
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 enableCONFIG_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
Signature · 5 lines
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"
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Hello Wolfgang,
Quoted 10 lines · Wolfgang Denk
Actually I think it is inherently wrong to enable
CONFIG_USE_PRIVATE_LIBGCCby 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_LIBGCCshould 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.
Quoted 3 lines
Best regards,
Wolfgang Denk
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
Quoted 12 lines
Hello Wolfgang,
Quoted 8 lines · Wolfgang Denk
Actually I think it is inherently wrong to enable
CONFIG_USE_PRIVATE_LIBGCCby 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.
Quoted 9 lines
Quoted 2 lines
CONFIG_USE_PRIVATE_LIBGCCshould 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_LIBGCCfor 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.
Signature · 1 line
- Daniel
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Hello Daniel,
(not sure how in my previous reply I managed to drop Masahiro off the discussion; fixing that, and apologies)
Quoted 38 lines · Daniel Schwierzeck
Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
Quoted 12 lines
Hello Wolfgang,
Quoted 8 lines · Wolfgang Denk
Actually I think it is inherently wrong to enable
CONFIG_USE_PRIVATE_LIBGCCby 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.
Quoted 9 lines
Quoted 2 lines
CONFIG_USE_PRIVATE_LIBGCCshould 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_LIBGCCfor 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_LIBGCCshould 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=yeswas the only painless way so far. That is why we chose to enableCONFIG_USE_PRIVATE_LIBGCCby default.
Quoted 1 line
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.
Quoted 2 lines
Signature · 1 line
- Daniel
Amicalement,
Signature · 1 line
Albert.
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
In reply to Daniel SchwierzeckDear Daniel,
Quoted 5 lines · In message <[email protected]> you wrote:
CONFIG_USE_PRIVATE_LIBGCCshould 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.
Quoted 3 lines
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.
Quoted 1 line
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
Signature · 4 lines
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!
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
2015-07-02 16:39 GMT+09:00 Wolfgang Denk <[email protected]>:
Quoted 26 lines
Dear Daniel,
Quoted 5 lines · In message <[email protected]> you wrote:
CONFIG_USE_PRIVATE_LIBGCCshould 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.
Quoted 3 lines
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.
Quoted 6 lines
Quoted 1 line
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 ?
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Dear Masahiro,
Quoted 7 lines · In message <CAK7LNATyqVrRn_3rPtsotF5JqF16rxqV0Z9LYCUjwzB4A7AFMw@mail.gmail.com>…
Quoted 4 lines
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
Signature · 6 lines
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
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
In reply to Wolfgang DenkAm 02.07.2015 um 09:39 schrieb Wolfgang Denk:
Quoted 12 lines
Dear Daniel,
Quoted 5 lines · In message <[email protected]> you wrote:
CONFIG_USE_PRIVATE_LIBGCCshould 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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 10 lines
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.
Quoted 1 line
BTW: Linux kernel or Barebox always use a private libgcc.
Quoted 8 lines
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.
Signature · 1 line
- Daniel
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Dear Daniel,
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 3 lines
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.
Quoted 3 lines
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".
Quoted 2 lines
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
Signature · 6 lines
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
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
In reply to Daniel Schwierzeck2015-07-02 8:39 GMT+09:00 Daniel Schwierzeck <[email protected]>:
Quoted 38 lines
Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
Quoted 12 lines
Hello Wolfgang,
Quoted 8 lines · Wolfgang Denk
Actually I think it is inherently wrong to enable
CONFIG_USE_PRIVATE_LIBGCCby 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.
Quoted 9 lines
Quoted 2 lines
CONFIG_USE_PRIVATE_LIBGCCshould 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_LIBGCCfor 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_LIBGCCshould 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=yeswas the only painless way so far. That is why we chose to enableCONFIG_USE_PRIVATE_LIBGCCby default.
Quoted 2 lines
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.)
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
2015-07-02 21:18 GMT+09:00 Masahiro Yamada <[email protected]>:
Quoted 43 lines
2015-07-02 8:39 GMT+09:00 Daniel Schwierzeck <[email protected]>:
Quoted 38 lines
Am 02.07.2015 um 00:04 schrieb Albert ARIBAUD:
Quoted 12 lines
Hello Wolfgang,
Quoted 8 lines · Wolfgang Denk
Actually I think it is inherently wrong to enable
CONFIG_USE_PRIVATE_LIBGCCby 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.
Quoted 9 lines
Quoted 2 lines
CONFIG_USE_PRIVATE_LIBGCCshould 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_LIBGCCfor 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_LIBGCCshould 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=yeswas the only painless way so far. That is why we chose to enableCONFIG_USE_PRIVATE_LIBGCCby default.Quoted 2 lines
BTW: Linux kernel or Barebox always use a private libgcc.
Quoted 8 lines
I agree with Daniel.
Instead of removing
CONFIG_USE_PRIVATE_LIBGCC,
I think it is better to "select" it byKconfig.(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.
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
In reply to Masahiro YamadaDear Masahiro,
Quoted 3 lines · In message <CAK7LNASsNVNj-neDO_7XT0t8RZO-EsHdP+WQGLbffxBrpR3pPg@mail.gmail.com>…
Instead of removing
CONFIG_USE_PRIVATE_LIBGCC,
I think it is better to "select" it byKconfig.
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.
Quoted 3 lines
(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
Signature · 6 lines
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
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
In reply to Albert ARIBAUDDear Albert,
Quoted 9 lines · In message <20150702000427.562195b4@lilith> you wrote:
Quoted 3 lines
CONFIG_USE_PRIVATE_LIBGCCshould 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_LIBGCCfor 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
Signature · 5 lines
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.
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Hi Wolfgang,
2015-07-02 16:34 GMT+09:00 Wolfgang Denk <[email protected]>:
Quoted 18 lines
Dear Albert,
Quoted 9 lines · In message <20150702000427.562195b4@lilith> you wrote:
Quoted 3 lines
CONFIG_USE_PRIVATE_LIBGCCshould 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_LIBGCCfor 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.
Quoted 8 lines
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
Quoted 8 lines
- 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.
Quoted 4 lines
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.
Signature · 2 lines
Best Regards Masahiro Yamada
PATCH 1/1 ARM: enable CONFIG_USE_PRIVATE_LIBGCC by default (re-send to the correct address)
Dear Masahiro,
Quoted 7 lines · In message <CAK7LNARHZB0mquGQjF4UOS4ztBsC2V3-jddJaYvbxmNB+i=MoQ@mail.gmail.com>…
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.
Quoted 4 lines
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
Signature · 4 lines
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