Current state of multilib support (powerpc)

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:



Alexey.

>
> Thanks,
> Thomas
>


--
For unsubscribe information see http://sourceware.org/lists.html#faq

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