Current state of multilib support (powerpc)

Current state of multilib support (powerpc)

[Thomas De Schampheleire]

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

Re: Current state of multilib support (powerpc)

[Bryan Hundven]

[-- 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 --]

Re: Current state of multilib support (powerpc)

[Thomas De Schampheleire]

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

Re: Current state of multilib support (powerpc)

[Bryan Hundven]

[-- 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 --]

Re: Current state of multilib support (powerpc)

[Alexey Neyman]

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

Re: Current state of multilib support (powerpc)

[Alexey Neyman]

[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

Re: Current state of multilib support (powerpc)

[Thomas De Schampheleire]

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

Re: Current state of multilib support (powerpc)

[Alexey Neyman]

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

Re: Current state of multilib support (powerpc)

[Thomas De Schampheleire]

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