* Current state of multilib support (powerpc) @ 2016-05-17 13:20 Thomas De Schampheleire 2016-05-17 13:50 ` Bryan Hundven 0 siblings, 1 reply; 9+ messages in thread From: Thomas De Schampheleire @ 2016-05-17 13:20 UTC (permalink / raw) To: crossgcc maillist, Ray Donnelly, Cody P Schafer, Bryan Hundven Hi, In 2014 there has been some work on multilib support in crosstool-ng, by Bryan Hundven, Cody P. Schafer, and Ray Donnelly. See e.g. mail threads [1] and [2]. It looks as if this work has not been integrated in crosstool-ng. Meanwhile also the bitbucket branch referenced in the threads no longer exists and I can't find the corresponding branches on github. What is the latest state of this work? Where are the latest patches? What are the remaining problems? I'm currently interested in a multilib toolchain 32/64 bit for Freescale e6500 processors. I ported one of Cody's patches to crosstool-ng 1.22.0 and the build advanced a bit further than with the 1.22.0 baseline, but now breaks at the 'pass-2 core C gcc compiler' step. Thanks, Thomas [1] https://sourceware.org/ml/crossgcc/2014-01/msg00054.html [2] https://sourceware.org/ml/crossgcc/2014-07/msg00014.html -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Current state of multilib support (powerpc) 2016-05-17 13:20 Current state of multilib support (powerpc) Thomas De Schampheleire @ 2016-05-17 13:50 ` Bryan Hundven 2016-05-18 12:34 ` Thomas De Schampheleire 0 siblings, 1 reply; 9+ messages in thread From: Bryan Hundven @ 2016-05-17 13:50 UTC (permalink / raw) To: Thomas De Schampheleire; +Cc: crossgcc maillist, Ray Donnelly, Cody P Schafer [-- Attachment #1: Type: text/plain, Size: 1255 bytes --] > On May 17, 2016, at 6:19 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > > Hi, > > In 2014 there has been some work on multilib support in crosstool-ng, > by Bryan Hundven, Cody P. Schafer, and Ray Donnelly. See e.g. mail > threads [1] and [2]. > > It looks as if this work has not been integrated in crosstool-ng. > Meanwhile also the bitbucket branch referenced in the threads no > longer exists and I can't find the corresponding branches on github. > > What is the latest state of this work? > Where are the latest patches? > What are the remaining problems? > > I'm currently interested in a multilib toolchain 32/64 bit for > Freescale e6500 processors. > I ported one of Cody's patches to crosstool-ng 1.22.0 and the build > advanced a bit further than with the 1.22.0 baseline, but now breaks > at the 'pass-2 core C gcc compiler' step. > > Thanks, > Thomas > > [1] https://sourceware.org/ml/crossgcc/2014-01/msg00054.html > [2] https://sourceware.org/ml/crossgcc/2014-07/msg00014.html (try 2: forgot gmail phone app replies with html mail) (try 1: forgot to reply all) See here: https://github.com/crosstool-ng/crosstool-ng/pull/383 Please test and review. Thanks, -Bryan [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Current state of multilib support (powerpc) 2016-05-17 13:50 ` Bryan Hundven @ 2016-05-18 12:34 ` Thomas De Schampheleire 2016-05-18 21:11 ` Bryan Hundven 0 siblings, 1 reply; 9+ messages in thread From: Thomas De Schampheleire @ 2016-05-18 12:34 UTC (permalink / raw) To: Bryan Hundven Cc: crossgcc maillist, Ray Donnelly, Cody P Schafer, Yann E. MORIN Hi Bryan, On Tue, May 17, 2016 at 3:50 PM, Bryan Hundven <bryanhundven@gmail.com> wrote: > >> On May 17, 2016, at 6:19 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: >> >> Hi, >> >> In 2014 there has been some work on multilib support in crosstool-ng, >> by Bryan Hundven, Cody P. Schafer, and Ray Donnelly. See e.g. mail >> threads [1] and [2]. >> >> It looks as if this work has not been integrated in crosstool-ng. >> Meanwhile also the bitbucket branch referenced in the threads no >> longer exists and I can't find the corresponding branches on github. >> >> What is the latest state of this work? >> Where are the latest patches? >> What are the remaining problems? >> >> I'm currently interested in a multilib toolchain 32/64 bit for >> Freescale e6500 processors. >> I ported one of Cody's patches to crosstool-ng 1.22.0 and the build >> advanced a bit further than with the 1.22.0 baseline, but now breaks >> at the 'pass-2 core C gcc compiler' step. >> >> Thanks, >> Thomas >> >> [1] https://sourceware.org/ml/crossgcc/2014-01/msg00054.html >> [2] https://sourceware.org/ml/crossgcc/2014-07/msg00014.html > > See here: https://github.com/crosstool-ng/crosstool-ng/pull/383 > > Please test and review. Interesting, thanks! I created a toolchain based on that PR with the following configuration: CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" CT_ARCH_CPU="e6500" CT_ARCH_64=y CT_ARCH_powerpc=y CT_MULTILIB=y CT_KERNEL_linux=y CT_KERNEL_V_3_18=y CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" CT_CC_GCC_V_4_9_3=y CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" CT_CC_GCC_MULTILIB_LIST="powerpc-linux,powerpc64-linux" CT_CC_LANG_CXX=y The idea is that 32-bit should be the default, without requiring additional options on the compiler command-line. When passing this toolchain to buildroot, applications seems to build fine in 32-bit (I did not try to run them yet). The kernel is also correctly built in 64-bit. However, there is something wrong for u-boot. I get errors like: /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: Relocatable linking with relocations from format elf32-powerpc (arch/powerpc/cpu/mpc8xxx/cpu.o) to format elf64-powerpc (arch/powerpc/cpu/mpc8xxx/built-in.o) is not supported which indicates that the default format used by ld.bfd is 64-bit rather than 32-bit. If I manually replay this command-line with the additional -m elf32ppc, it seems to work correctly and a 32-bit builtin.o is created. What am I missing? Why is ld not taking 32-bit as default, while gcc is? (I did not post to the github PR because it may all be caused by a misconfiguration or misunderstanding on my part). Thanks, Thomas -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Current state of multilib support (powerpc) 2016-05-18 12:34 ` Thomas De Schampheleire @ 2016-05-18 21:11 ` Bryan Hundven 2016-05-19 4:46 ` Alexey Neyman 2016-05-19 4:55 ` Alexey Neyman 0 siblings, 2 replies; 9+ messages in thread From: Bryan Hundven @ 2016-05-18 21:11 UTC (permalink / raw) To: Thomas De Schampheleire Cc: crossgcc maillist, Ray Donnelly, Cody P Schafer, Yann E. MORIN, Alexey Neyman [-- Attachment #1: Type: text/plain, Size: 3233 bytes --] (Added Alexey Neyman, who did the multilib work) > On May 18, 2016, at 5:33 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: > > Hi Bryan, > > On Tue, May 17, 2016 at 3:50 PM, Bryan Hundven <bryanhundven@gmail.com> wrote: >> >>> On May 17, 2016, at 6:19 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: >>> >>> Hi, >>> >>> In 2014 there has been some work on multilib support in crosstool-ng, >>> by Bryan Hundven, Cody P. Schafer, and Ray Donnelly. See e.g. mail >>> threads [1] and [2]. >>> >>> It looks as if this work has not been integrated in crosstool-ng. >>> Meanwhile also the bitbucket branch referenced in the threads no >>> longer exists and I can't find the corresponding branches on github. >>> >>> What is the latest state of this work? >>> Where are the latest patches? >>> What are the remaining problems? >>> >>> I'm currently interested in a multilib toolchain 32/64 bit for >>> Freescale e6500 processors. >>> I ported one of Cody's patches to crosstool-ng 1.22.0 and the build >>> advanced a bit further than with the 1.22.0 baseline, but now breaks >>> at the 'pass-2 core C gcc compiler' step. >>> >>> Thanks, >>> Thomas >>> >>> [1] https://sourceware.org/ml/crossgcc/2014-01/msg00054.html >>> [2] https://sourceware.org/ml/crossgcc/2014-07/msg00014.html >> >> See here: https://github.com/crosstool-ng/crosstool-ng/pull/383 >> >> Please test and review. Alexey, could you help out with this one? > > Interesting, thanks! > > I created a toolchain based on that PR with the following configuration: > > CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" > CT_ARCH_CPU="e6500" > CT_ARCH_64=y > CT_ARCH_powerpc=y > CT_MULTILIB=y > CT_KERNEL_linux=y > CT_KERNEL_V_3_18=y > CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > CT_CC_GCC_V_4_9_3=y > CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > CT_CC_GCC_MULTILIB_LIST="powerpc-linux,powerpc64-linux" > CT_CC_LANG_CXX=y > > The idea is that 32-bit should be the default, without requiring > additional options on the compiler command-line. > > When passing this toolchain to buildroot, applications seems to build > fine in 32-bit (I did not try to run them yet). > The kernel is also correctly built in 64-bit. > However, there is something wrong for u-boot. I get errors like: > > /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: > Relocatable linking with relocations from format elf32-powerpc > (arch/powerpc/cpu/mpc8xxx/cpu.o) to format elf64-powerpc > (arch/powerpc/cpu/mpc8xxx/built-in.o) is not supported > > which indicates that the default format used by ld.bfd is 64-bit > rather than 32-bit. If I manually replay this command-line with the > additional -m elf32ppc, it seems to work correctly and a 32-bit > builtin.o is created. > > What am I missing? Why is ld not taking 32-bit as default, while gcc is? > > (I did not post to the github PR because it may all be caused by a > misconfiguration or misunderstanding on my part). > > Thanks, > Thomas [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Current state of multilib support (powerpc) 2016-05-18 21:11 ` Bryan Hundven @ 2016-05-19 4:46 ` Alexey Neyman 2016-05-19 4:55 ` Alexey Neyman 1 sibling, 0 replies; 9+ messages in thread From: Alexey Neyman @ 2016-05-19 4:46 UTC (permalink / raw) To: Bryan Hundven, Thomas De Schampheleire Cc: crossgcc maillist, Ray Donnelly, Cody P Schafer, Yann E. MORIN Hi, On 05/18/2016 02:11 PM, Bryan Hundven wrote: > (Added Alexey Neyman, who did the multilib work) >> On May 18, 2016, at 5:33 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: >> >> Hi Bryan, >> >> On Tue, May 17, 2016 at 3:50 PM, Bryan Hundven <bryanhundven@gmail.com> wrote: >>>> On May 17, 2016, at 6:19 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> In 2014 there has been some work on multilib support in crosstool-ng, >>>> by Bryan Hundven, Cody P. Schafer, and Ray Donnelly. See e.g. mail >>>> threads [1] and [2]. >>>> >>>> It looks as if this work has not been integrated in crosstool-ng. >>>> Meanwhile also the bitbucket branch referenced in the threads no >>>> longer exists and I can't find the corresponding branches on github. >>>> >>>> What is the latest state of this work? >>>> Where are the latest patches? >>>> What are the remaining problems? >>>> >>>> I'm currently interested in a multilib toolchain 32/64 bit for >>>> Freescale e6500 processors. >>>> I ported one of Cody's patches to crosstool-ng 1.22.0 and the build >>>> advanced a bit further than with the 1.22.0 baseline, but now breaks >>>> at the 'pass-2 core C gcc compiler' step. >>>> >>>> Thanks, >>>> Thomas >>>> >>>> [1] https://sourceware.org/ml/crossgcc/2014-01/msg00054.html >>>> [2] https://sourceware.org/ml/crossgcc/2014-07/msg00014.html >>> See here: https://github.com/crosstool-ng/crosstool-ng/pull/383 >>> >>> Please test and review. > Alexey, could you help out with this one? > >> Interesting, thanks! >> >> I created a toolchain based on that PR with the following configuration: >> >> CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" >> CT_ARCH_CPU="e6500" >> CT_ARCH_64=y >> CT_ARCH_powerpc=y >> CT_MULTILIB=y >> CT_KERNEL_linux=y >> CT_KERNEL_V_3_18=y >> CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >> CT_CC_GCC_V_4_9_3=y >> CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >> CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >> CT_CC_GCC_MULTILIB_LIST="powerpc-linux,powerpc64-linux" >> CT_CC_LANG_CXX=y >> >> The idea is that 32-bit should be the default, without requiring >> additional options on the compiler command-line. >> >> When passing this toolchain to buildroot, applications seems to build >> fine in 32-bit (I did not try to run them yet). >> The kernel is also correctly built in 64-bit. >> However, there is something wrong for u-boot. I get errors like: >> >> /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: >> Relocatable linking with relocations from format elf32-powerpc >> (arch/powerpc/cpu/mpc8xxx/cpu.o) to format elf64-powerpc >> (arch/powerpc/cpu/mpc8xxx/built-in.o) is not supported >> >> which indicates that the default format used by ld.bfd is 64-bit >> rather than 32-bit. If I manually replay this command-line with the >> additional -m elf32ppc, it seems to work correctly and a 32-bit >> builtin.o is created. >> >> What am I missing? Why is ld not taking 32-bit as default, while gcc is? >> >> (I did not post to the github PR because it may all be caused by a >> misconfiguration or misunderstanding on my part). >> >> Thanks, >> Thomas -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Current state of multilib support (powerpc) 2016-05-18 21:11 ` Bryan Hundven 2016-05-19 4:46 ` Alexey Neyman @ 2016-05-19 4:55 ` Alexey Neyman [not found] ` <CAAXf6LX3cPe2eF2BDfGiLDdCMbBq8TxPFGCWYawB8wCZ-yj-Xg@mail.gmail.com> 1 sibling, 1 reply; 9+ messages in thread From: Alexey Neyman @ 2016-05-19 4:55 UTC (permalink / raw) To: Bryan Hundven, Thomas De Schampheleire Cc: crossgcc maillist, Ray Donnelly, Cody P Schafer, Yann E. MORIN [Sorry for previous emails; fat fingers hit send accidentally] Hi, On 05/18/2016 02:11 PM, Bryan Hundven wrote: > (Added Alexey Neyman, who did the multilib work) >> On May 18, 2016, at 5:33 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: >> >> Hi Bryan, >> >> On Tue, May 17, 2016 at 3:50 PM, Bryan Hundven <bryanhundven@gmail.com> wrote: >>>> On May 17, 2016, at 6:19 AM, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> In 2014 there has been some work on multilib support in crosstool-ng, >>>> by Bryan Hundven, Cody P. Schafer, and Ray Donnelly. See e.g. mail >>>> threads [1] and [2]. >>>> >>>> It looks as if this work has not been integrated in crosstool-ng. >>>> Meanwhile also the bitbucket branch referenced in the threads no >>>> longer exists and I can't find the corresponding branches on github. >>>> >>>> What is the latest state of this work? >>>> Where are the latest patches? >>>> What are the remaining problems? >>>> >>>> I'm currently interested in a multilib toolchain 32/64 bit for >>>> Freescale e6500 processors. >>>> I ported one of Cody's patches to crosstool-ng 1.22.0 and the build >>>> advanced a bit further than with the 1.22.0 baseline, but now breaks >>>> at the 'pass-2 core C gcc compiler' step. >>>> >>>> Thanks, >>>> Thomas >>>> >>>> [1] https://sourceware.org/ml/crossgcc/2014-01/msg00054.html >>>> [2] https://sourceware.org/ml/crossgcc/2014-07/msg00014.html >>> See here: https://github.com/crosstool-ng/crosstool-ng/pull/383 >>> >>> Please test and review. > Alexey, could you help out with this one? > >> Interesting, thanks! >> >> I created a toolchain based on that PR with the following configuration: >> >> CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" >> CT_ARCH_CPU="e6500" >> CT_ARCH_64=y >> CT_ARCH_powerpc=y >> CT_MULTILIB=y >> CT_KERNEL_linux=y >> CT_KERNEL_V_3_18=y >> CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >> CT_CC_GCC_V_4_9_3=y >> CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >> CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >> CT_CC_GCC_MULTILIB_LIST="powerpc-linux,powerpc64-linux" >> CT_CC_LANG_CXX=y >> >> The idea is that 32-bit should be the default, without requiring >> additional options on the compiler command-line. >> >> When passing this toolchain to buildroot, applications seems to build >> fine in 32-bit (I did not try to run them yet). >> The kernel is also correctly built in 64-bit. >> However, there is something wrong for u-boot. I get errors like: The fact that both 32- and 64-bit applications compile fine indicate that gcc indeed is passing the options to ld correctly. I tried building a simple app in 32- and 64-bit modes, with -v, and the output shows that in 64-bit mode, -m64 is added to the arguments - as expected. >> >> /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: >> Relocatable linking with relocations from format elf32-powerpc >> (arch/powerpc/cpu/mpc8xxx/cpu.o) to format elf64-powerpc >> (arch/powerpc/cpu/mpc8xxx/built-in.o) is not supported Which target are you building? I tried some random powerpc target (xpedite517x_defconfig) and the build failed due to some invalid assembly but went past mpc8xxx/built-in.o: CC arch/powerpc/cpu/mpc8xxx/cpu.o CC arch/powerpc/cpu/mpc8xxx/fdt.o CC arch/powerpc/cpu/mpc8xxx/fsl_lbc.o CC arch/powerpc/cpu/mpc8xxx/law.o LD arch/powerpc/cpu/mpc8xxx/built-in.o LD arch/powerpc/cpu/built-in.o AS arch/powerpc/cpu/mpc86xx/cache.o CC arch/powerpc/cpu/mpc86xx/cpu.o CC arch/powerpc/cpu/mpc86xx/cpu_init.o CC arch/powerpc/cpu/mpc86xx/fdt.o CC arch/powerpc/cpu/mpc86xx/interrupts.o CC arch/powerpc/cpu/mpc86xx/mpc8641_serdes.o CC arch/powerpc/cpu/mpc86xx/speed.o LD arch/powerpc/cpu/mpc86xx/built-in.o AS arch/powerpc/cpu/mpc86xx/start.o arch/powerpc/cpu/mpc86xx/start.S: Assembler messages: arch/powerpc/cpu/mpc86xx/start.S:466: Error: missing operand Hard to say what went wrong without the name of the target that failed for you. It looks, however, like U-Boot's build system expects binutils/gcc to default to exact CPU for the target - not surprising given the variety of PowerPC assembly dialects... Regards, Alexey. >> >> which indicates that the default format used by ld.bfd is 64-bit >> rather than 32-bit. If I manually replay this command-line with the >> additional -m elf32ppc, it seems to work correctly and a 32-bit >> builtin.o is created. >> >> What am I missing? Why is ld not taking 32-bit as default, while gcc is? >> >> (I did not post to the github PR because it may all be caused by a >> misconfiguration or misunderstanding on my part). >> >> Thanks, >> Thomas -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <CAAXf6LX3cPe2eF2BDfGiLDdCMbBq8TxPFGCWYawB8wCZ-yj-Xg@mail.gmail.com>]
[parent not found: <573D596D.9020505@att.net>]
* Re: Current state of multilib support (powerpc) [not found] ` <573D596D.9020505@att.net> @ 2016-05-19 7:15 ` Thomas De Schampheleire 2016-05-21 5:22 ` Alexey Neyman 0 siblings, 1 reply; 9+ messages in thread From: Thomas De Schampheleire @ 2016-05-19 7:15 UTC (permalink / raw) To: Alexey Neyman Cc: Cody P Schafer, Yann E. MORIN, Ray Donnelly, crossgcc maillist, Bryan Hundven On Thu, May 19, 2016 at 8:13 AM, Alexey Neyman <stilor@att.net> wrote: [..] >>>> >>>> I created a toolchain based on that PR with the following configuration: >>>> >>>> CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" >>>> CT_ARCH_CPU="e6500" >>>> CT_ARCH_64=y >>>> CT_ARCH_powerpc=y >>>> CT_MULTILIB=y >>>> CT_KERNEL_linux=y >>>> CT_KERNEL_V_3_18=y >>>> >>>> CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >>>> CT_CC_GCC_V_4_9_3=y >>>> >>>> CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >>>> >>>> CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >>>> CT_CC_GCC_MULTILIB_LIST="powerpc-linux,powerpc64-linux" >>>> CT_CC_LANG_CXX=y >>>> >>>> The idea is that 32-bit should be the default, without requiring >>>> additional options on the compiler command-line. >>>> >>>> When passing this toolchain to buildroot, applications seems to build >>>> fine in 32-bit (I did not try to run them yet). >>>> The kernel is also correctly built in 64-bit. >>>> However, there is something wrong for u-boot. I get errors like: >> >> The fact that both 32- and 64-bit applications compile fine indicate that >> gcc indeed is passing the options to ld correctly. I tried building a simple >> app in 32- and 64-bit modes, with -v, and the output shows that in 64-bit >> mode, -m64 is added to the arguments - as expected. >> >>>> >>>> /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: >>>> Relocatable linking with relocations from format elf32-powerpc >>>> (arch/powerpc/cpu/mpc8xxx/cpu.o) to format elf64-powerpc >>>> (arch/powerpc/cpu/mpc8xxx/built-in.o) is not supported >> >> Which target are you building? I tried some random powerpc target >> (xpedite517x_defconfig) and the build failed due to some invalid assembly >> but went past mpc8xxx/built-in.o: >> >> CC arch/powerpc/cpu/mpc8xxx/cpu.o >> CC arch/powerpc/cpu/mpc8xxx/fdt.o >> CC arch/powerpc/cpu/mpc8xxx/fsl_lbc.o >> CC arch/powerpc/cpu/mpc8xxx/law.o >> LD arch/powerpc/cpu/mpc8xxx/built-in.o >> LD arch/powerpc/cpu/built-in.o >> AS arch/powerpc/cpu/mpc86xx/cache.o >> CC arch/powerpc/cpu/mpc86xx/cpu.o >> CC arch/powerpc/cpu/mpc86xx/cpu_init.o >> CC arch/powerpc/cpu/mpc86xx/fdt.o >> CC arch/powerpc/cpu/mpc86xx/interrupts.o >> CC arch/powerpc/cpu/mpc86xx/mpc8641_serdes.o >> CC arch/powerpc/cpu/mpc86xx/speed.o >> LD arch/powerpc/cpu/mpc86xx/built-in.o >> AS arch/powerpc/cpu/mpc86xx/start.o >> arch/powerpc/cpu/mpc86xx/start.S: Assembler messages: >> arch/powerpc/cpu/mpc86xx/start.S:466: Error: missing operand >> >> Hard to say what went wrong without the name of the target that failed for >> you. It looks, however, like U-Boot's build system expects binutils/gcc to >> default to exact CPU for the target - not surprising given the variety of >> PowerPC assembly dialects... >> > > The target is a custom board not available in upstream uboot. It is based on > Freescale T2080. I don't have the repo at hand, I can check later if there > is a similar upstream target that shows the same problem... > > If you cannot find a similar board, at least capture the commands that > compiled the objects that went into linking, and the link command itself. > With a bit of luck that may be sufficient to reproduce the issue :) > I can reproduce the issue with the upstream config called 'T2080RDB'. Excerpt from the log: /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-gcc -Wp,-MD,board/freescale/common/.fman.o.d -nostdinc -isystem /foo/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-unknown-linux-gnu/4.9.3/include -Iinclude -I./arch/powerpc/include -I./board/isam_common -I./board/freescale/t208xrdb -include ./include/linux/kconfig.h -D__KERNEL__ -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0xeff40000 -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -Os -fno-stack-protector -g -fstack-usage -Wno-format-nonliteral -Werror=date-time -D__powerpc__ -ffixed-r2 -Wa,-me500 -msoft-float -mno-string -fno-delete-null-pointer-checks -mno-spe -fpic -mrelocatable -ffunction-sections -fdata-sections -meabi -pipe -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fman)" -D"KBUILD_MODNAME=KBUILD_STR(fman)" -c -o board/freescale/common/fman.o board/freescale/common/fman.c /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd -n -r -o board/freescale/common/built-in.o board/freescale/common/fman.o board/freescale/common/vid.o board/freescale/common/sys_eeprom.o /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: Relocatable linking with relocations from format elf32-powerpc (board/freescale/common/fman.o) to format elf64-powerpc (board/freescale/common/built-in.o) is not supported s Be aware that I'm building with Buildroot, meaning that the compiler (not linker) is wrapped. When calling that wrapper, the real compiler is called with following extra options: --sysroot' '/home/tdescham/repo/isam/buildroot-fantg/output/host/usr/powerpc-buildroot-linux-gnu/sysroot' '-mcpu=e6500' Thanks, Thomas -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Current state of multilib support (powerpc) 2016-05-19 7:15 ` Thomas De Schampheleire @ 2016-05-21 5:22 ` Alexey Neyman 2016-05-21 19:46 ` Thomas De Schampheleire 0 siblings, 1 reply; 9+ messages in thread From: Alexey Neyman @ 2016-05-21 5:22 UTC (permalink / raw) To: Thomas De Schampheleire Cc: Cody P Schafer, Yann E. MORIN, Ray Donnelly, crossgcc maillist, Bryan Hundven On 05/19/2016 12:15 AM, Thomas De Schampheleire wrote: > On Thu, May 19, 2016 at 8:13 AM, Alexey Neyman <stilor@att.net> wrote: > [..] >>>>> I created a toolchain based on that PR with the following configuration: >>>>> >>>>> CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" >>>>> CT_ARCH_CPU="e6500" >>>>> CT_ARCH_64=y >>>>> CT_ARCH_powerpc=y >>>>> CT_MULTILIB=y >>>>> CT_KERNEL_linux=y >>>>> CT_KERNEL_V_3_18=y >>>>> >>>>> CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >>>>> CT_CC_GCC_V_4_9_3=y >>>>> >>>>> CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >>>>> >>>>> CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" >>>>> CT_CC_GCC_MULTILIB_LIST="powerpc-linux,powerpc64-linux" >>>>> CT_CC_LANG_CXX=y >>>>> >>>>> The idea is that 32-bit should be the default, without requiring >>>>> additional options on the compiler command-line. >>>>> >>>>> When passing this toolchain to buildroot, applications seems to build >>>>> fine in 32-bit (I did not try to run them yet). >>>>> The kernel is also correctly built in 64-bit. >>>>> However, there is something wrong for u-boot. I get errors like: >>> The fact that both 32- and 64-bit applications compile fine indicate that >>> gcc indeed is passing the options to ld correctly. I tried building a simple >>> app in 32- and 64-bit modes, with -v, and the output shows that in 64-bit >>> mode, -m64 is added to the arguments - as expected. >>> >>>>> /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: >>>>> Relocatable linking with relocations from format elf32-powerpc >>>>> (arch/powerpc/cpu/mpc8xxx/cpu.o) to format elf64-powerpc >>>>> (arch/powerpc/cpu/mpc8xxx/built-in.o) is not supported >>> Which target are you building? I tried some random powerpc target >>> (xpedite517x_defconfig) and the build failed due to some invalid assembly >>> but went past mpc8xxx/built-in.o: >>> >>> CC arch/powerpc/cpu/mpc8xxx/cpu.o >>> CC arch/powerpc/cpu/mpc8xxx/fdt.o >>> CC arch/powerpc/cpu/mpc8xxx/fsl_lbc.o >>> CC arch/powerpc/cpu/mpc8xxx/law.o >>> LD arch/powerpc/cpu/mpc8xxx/built-in.o >>> LD arch/powerpc/cpu/built-in.o >>> AS arch/powerpc/cpu/mpc86xx/cache.o >>> CC arch/powerpc/cpu/mpc86xx/cpu.o >>> CC arch/powerpc/cpu/mpc86xx/cpu_init.o >>> CC arch/powerpc/cpu/mpc86xx/fdt.o >>> CC arch/powerpc/cpu/mpc86xx/interrupts.o >>> CC arch/powerpc/cpu/mpc86xx/mpc8641_serdes.o >>> CC arch/powerpc/cpu/mpc86xx/speed.o >>> LD arch/powerpc/cpu/mpc86xx/built-in.o >>> AS arch/powerpc/cpu/mpc86xx/start.o >>> arch/powerpc/cpu/mpc86xx/start.S: Assembler messages: >>> arch/powerpc/cpu/mpc86xx/start.S:466: Error: missing operand >>> >>> Hard to say what went wrong without the name of the target that failed for >>> you. It looks, however, like U-Boot's build system expects binutils/gcc to >>> default to exact CPU for the target - not surprising given the variety of >>> PowerPC assembly dialects... >>> >> The target is a custom board not available in upstream uboot. It is based on >> Freescale T2080. I don't have the repo at hand, I can check later if there >> is a similar upstream target that shows the same problem... >> >> If you cannot find a similar board, at least capture the commands that >> compiled the objects that went into linking, and the link command itself. >> With a bit of luck that may be sufficient to reproduce the issue :) >> > > I can reproduce the issue with the upstream config called 'T2080RDB'. > Excerpt from the log: > > > /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-gcc > -Wp,-MD,board/freescale/common/.fman.o.d -nostdinc -isystem > /foo/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-unknown-linux-gnu/4.9.3/include > -Iinclude -I./arch/powerpc/include -I./board/isam_common > -I./board/freescale/t208xrdb -include ./include/linux/kconfig.h > -D__KERNEL__ -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0xeff40000 -Wall > -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding > -Os -fno-stack-protector -g -fstack-usage -Wno-format-nonliteral > -Werror=date-time -D__powerpc__ -ffixed-r2 -Wa,-me500 -msoft-float > -mno-string -fno-delete-null-pointer-checks -mno-spe -fpic > -mrelocatable -ffunction-sections -fdata-sections -meabi -pipe > -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fman)" > -D"KBUILD_MODNAME=KBUILD_STR(fman)" -c -o > board/freescale/common/fman.o board/freescale/common/fman.c > > /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd -n -r > -o board/freescale/common/built-in.o board/freescale/common/fman.o > board/freescale/common/vid.o board/freescale/common/sys_eeprom.o > > /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: > Relocatable linking with relocations from format elf32-powerpc > (board/freescale/common/fman.o) to format elf64-powerpc > (board/freescale/common/built-in.o) is not supported > s > > > Be aware that I'm building with Buildroot, meaning that the compiler > (not linker) is wrapped. When calling that wrapper, the real compiler > is called with following extra options: > > --sysroot' '/home/tdescham/repo/isam/buildroot-fantg/output/host/usr/powerpc-buildroot-linux-gnu/sysroot' > '-mcpu=e6500' I don't have your buildroot tree; I tried creating the wrapper with just -mcpu=e6500 added. But it fails in U-Boot build for T2080_RDB even before linking built-in.o: CC arch/powerpc/cpu/mpc8xxx/cpu.o {standard input}: Assembler messages: {standard input}:512: Error: junk at end of line: `128' scripts/Makefile.build:280: recipe for target 'arch/powerpc/cpu/mpc8xxx/cpu.o' failed make[2]: *** [arch/powerpc/cpu/mpc8xxx/cpu.o] Error 1 Using U-Boot 2016.05. Which version are you using? Is it possible that the sysroot contains something that changes GCC options (e.g. a gcc spec file)? I did reproduce your issue, though, by running the commands you quoted above, manually. The problem is that U-boot invokes ld directly, not through gcc; and ld is indeed defaulting to 64-bit. You toolchain config supplies --enable-targets to binutils configure, but binutils configure does not handle this option; the preferred mode is established by the supplied target. Hence, you should build for powerpc, not for powerpc64 - that still allows --enable-targets option to gcc configure, so you'll still be able to build 64-bit binaries: --- email-defconfig 2016-05-18 20:02:57.565718947 -0700 +++ email-defconfig.mod 2016-05-20 20:34:22.566050597 -0700 @@ -1,11 +1,9 @@ CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" CT_ARCH_CPU="e6500" -CT_ARCH_64=y CT_ARCH_powerpc=y CT_MULTILIB=y CT_KERNEL_linux=y CT_KERNEL_V_3_18=y -CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" CT_CC_GCC_V_4_9_3=y CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" Alexey. > > Thanks, > Thomas > -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Current state of multilib support (powerpc) 2016-05-21 5:22 ` Alexey Neyman @ 2016-05-21 19:46 ` Thomas De Schampheleire 0 siblings, 0 replies; 9+ messages in thread From: Thomas De Schampheleire @ 2016-05-21 19:46 UTC (permalink / raw) To: Alexey Neyman Cc: Cody P Schafer, Yann E. MORIN, Ray Donnelly, crossgcc maillist, Bryan Hundven On Sat, May 21, 2016 at 7:22 AM, Alexey Neyman <stilor@att.net> wrote: > > > On 05/19/2016 12:15 AM, Thomas De Schampheleire wrote: >> [..] >> >> I can reproduce the issue with the upstream config called 'T2080RDB'. >> Excerpt from the log: >> >> >> /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-gcc >> -Wp,-MD,board/freescale/common/.fman.o.d -nostdinc -isystem >> >> /foo/output/host/opt/ext-toolchain/bin/../lib/gcc/powerpc64-unknown-linux-gnu/4.9.3/include >> -Iinclude -I./arch/powerpc/include -I./board/isam_common >> -I./board/freescale/t208xrdb -include ./include/linux/kconfig.h >> -D__KERNEL__ -D__UBOOT__ -DCONFIG_SYS_TEXT_BASE=0xeff40000 -Wall >> -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding >> -Os -fno-stack-protector -g -fstack-usage -Wno-format-nonliteral >> -Werror=date-time -D__powerpc__ -ffixed-r2 -Wa,-me500 -msoft-float >> -mno-string -fno-delete-null-pointer-checks -mno-spe -fpic >> -mrelocatable -ffunction-sections -fdata-sections -meabi -pipe >> -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(fman)" >> -D"KBUILD_MODNAME=KBUILD_STR(fman)" -c -o >> board/freescale/common/fman.o board/freescale/common/fman.c >> >> /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd -n -r >> -o board/freescale/common/built-in.o board/freescale/common/fman.o >> board/freescale/common/vid.o board/freescale/common/sys_eeprom.o >> >> /foo/output/host/usr/bin/powerpc64-unknown-linux-gnu-ld.bfd: >> Relocatable linking with relocations from format elf32-powerpc >> (board/freescale/common/fman.o) to format elf64-powerpc >> (board/freescale/common/built-in.o) is not supported >> s >> >> >> Be aware that I'm building with Buildroot, meaning that the compiler >> (not linker) is wrapped. When calling that wrapper, the real compiler >> is called with following extra options: >> >> --sysroot' >> '/home/tdescham/repo/isam/buildroot-fantg/output/host/usr/powerpc-buildroot-linux-gnu/sysroot' >> '-mcpu=e6500' > > I don't have your buildroot tree; I tried creating the wrapper with just > -mcpu=e6500 added. But it fails in U-Boot build for T2080_RDB even before > linking built-in.o: > > CC arch/powerpc/cpu/mpc8xxx/cpu.o > {standard input}: Assembler messages: > {standard input}:512: Error: junk at end of line: `128' > scripts/Makefile.build:280: recipe for target > 'arch/powerpc/cpu/mpc8xxx/cpu.o' failed > make[2]: *** [arch/powerpc/cpu/mpc8xxx/cpu.o] Error 1 Yes, I saw those same messages too (Buildroot builds u-boot in parallel by default so it did not immediately fail the entire build). > > Using U-Boot 2016.05. Which version are you using? Is it possible that the > sysroot contains something that changes GCC options (e.g. a gcc spec file)? This is based on U-Boot 2015.01. We are not manually playing with anything like spec files. The toolchain produced by crosstool-ng is archived and configured in Buildroot as external toolchain. Then the usual Buildroot toolchain logic is applied, which basically is unpacking part of the archive, and producing a wrapper for the compiler that passing the necessary --sysroot, -march/mtune/mcpu, etc. options as configured by the user or built-in in Buildroot. > > > I did reproduce your issue, though, by running the commands you quoted > above, manually. > > The problem is that U-boot invokes ld directly, not through gcc; and ld is > indeed defaulting to 64-bit. Such issues pass by in Buildroot regularly. There have been discussions on producing a wrapper for ld too, which can then explicitly give the right flags e.g. -m32 in this case. So far it's not done. > You toolchain config supplies --enable-targets > to binutils configure, but binutils configure does not handle this option; > the preferred mode is established by the supplied target. > > Hence, you should build for powerpc, not for powerpc64 - that still allows > --enable-targets option to gcc configure, so you'll still be able to build > 64-bit binaries: > > --- email-defconfig 2016-05-18 20:02:57.565718947 -0700 > +++ email-defconfig.mod 2016-05-20 20:34:22.566050597 -0700 > @@ -1,11 +1,9 @@ > CT_PREFIX_DIR="${CT_TOP_DIR}/targets/${CT_TARGET}" > CT_ARCH_CPU="e6500" > -CT_ARCH_64=y > CT_ARCH_powerpc=y > CT_MULTILIB=y > CT_KERNEL_linux=y > CT_KERNEL_V_3_18=y > -CT_BINUTILS_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > CT_CC_GCC_V_4_9_3=y > > CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > > CT_CC_GCC_EXTRA_CONFIG_ARRAY="--enable-targets=powerpc-linux,powerpc64-linux" > Thanks! With this config I was able to build u-boot just fine (on the T2080RDB defconfig I still had the 'junk at end of line' assembler messages, but not on my real board). I will now further evaluate the generated image. In any case it looks like the toolchain works fine now, and the pull request is doing its job. Thanks for your help, Thomas -- For unsubscribe information see http://sourceware.org/lists.html#faq ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2016-05-21 19:46 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-17 13:20 Current state of multilib support (powerpc) Thomas De Schampheleire 2016-05-17 13:50 ` Bryan Hundven 2016-05-18 12:34 ` Thomas De Schampheleire 2016-05-18 21:11 ` Bryan Hundven 2016-05-19 4:46 ` Alexey Neyman 2016-05-19 4:55 ` Alexey Neyman [not found] ` <CAAXf6LX3cPe2eF2BDfGiLDdCMbBq8TxPFGCWYawB8wCZ-yj-Xg@mail.gmail.com> [not found] ` <573D596D.9020505@att.net> 2016-05-19 7:15 ` Thomas De Schampheleire 2016-05-21 5:22 ` Alexey Neyman 2016-05-21 19:46 ` Thomas De Schampheleire
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).