boot/wrap assumes a biarch toolchain?

boot/wrap assumes a biarch toolchain?

[Anton Blanchard]

Hi,

Jan is seeing the following fail:

WRAP    arch/powerpc/boot/zImage.pmac
powerpc-linux-objcopy: vmlinux: File format not recognized

He is using a cross compile toolchain invoked with the following command
line:

# make HOSTCC=gcc-4.0 ARCH=powerpc CROSS_COMPILE=powerpc64-linux- CROSS32_COMPILE=powerpc-linux-

It seems like boot/wrap wants to use both 64bit and 32bit tools, however
it only receives the 32bit path:

ifneq ($(CROSS32_COMPILE),)
CROSSWRAP := -C "$(CROSS32_COMPILE)"
else
ifneq ($(CROSS_COMPILE),)
CROSSWRAP := -C "$(CROSS_COMPILE)"
endif
endif

Thoughts? I guess we have to pass in both cross compile targets.

One way to make this go away would be to build binutils as biarch:

# configure --target=powerpc-linux --enable-targets=powerpc64-linux ...

Anton

Re: boot/wrap assumes a biarch toolchain?

[Andreas Schwab]

Anton Blanchard <anton@samba.org> writes:

> One way to make this go away would be to build binutils as biarch:
>
> # configure --target=powerpc-linux --enable-targets=powerpc64-linux ...

If you configure your toolchain for powerpc64-linux you get a biarch
toolchain by default.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: boot/wrap assumes a biarch toolchain?

[Jan Dittmer]

Andreas Schwab wrote:
> Anton Blanchard <anton@samba.org> writes:
> 
>> One way to make this go away would be to build binutils as biarch:
>>
>> # configure --target=powerpc-linux --enable-targets=powerpc64-linux ...
> 
> If you configure your toolchain for powerpc64-linux you get a biarch
> toolchain by default.

Hmm:

$ powerpc64-linux-ld -V
GNU ld (Linux/GNU Binutils) 2.17.50.0.17.20070615
   Supported emulations:
    elf64ppc
    elf32ppclinux
    elf32ppc
    elf32ppcsim

$ powerpc64-linux-gcc-4.0.4 -v
Using built-in specs.
Target: powerpc64-linux
Configured with: ../configure --prefix=/usr/cc217 
--exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux --disable-shared 
--disable-werror --disable-nls --disable-threads --disable-werror 
--disable-libmudflap --with-newlib --with-gnu-as --with-gnu-ld 
--enable-languages=c
Thread model: single
gcc version 4.0.4

g5_defconfig:

$ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- 
CROSS32_COMPILE=powerpc64-linux-
...
   CC      arch/powerpc/kernel/signal.o
   LDS     arch/powerpc/kernel/vdso32/vdso32.lds
   VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o
   VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S: Assembler 
messages:
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33: Error: 
syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33: Error: 
junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37: Error: 
syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37: Error: 
junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95: Error: 
syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95: Error: 
junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103: Error: 
syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103: Error: 
junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130: Error: 
syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130: Error: 
junk at end of line: `@local'
make[3]: *** [arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
make[2]: *** [arch/powerpc/kernel/vdso32] Error 2
make[1]: *** [arch/powerpc/kernel] Error 2
make: *** [sub-make] Error 2


Jan

Re: boot/wrap assumes a biarch toolchain?

[Anton Blanchard]

 
Hi,

> If you configure your toolchain for powerpc64-linux you get a biarch
> toolchain by default.

I was wondering about people using pre biarch gcc toolchains. But I take
your point - I'm guessing binutils has been biarch for a long time.
Since we are only calling binutils functions in boot/wrap, maybe we can
just do:

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 18e3271..8961afd 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -121,13 +121,9 @@ wrapperbits	:= $(extra-y) $(addprefix $(obj)/,addnote hack-coff mktree) \
 #############
 # Bits for building various flavours of zImage
 
-ifneq ($(CROSS32_COMPILE),)
-CROSSWRAP := -C "$(CROSS32_COMPILE)"
-else
 ifneq ($(CROSS_COMPILE),)
 CROSSWRAP := -C "$(CROSS_COMPILE)"
 endif
-endif
 
 # args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
 quiet_cmd_wrap	= WRAP    $@

Re: boot/wrap assumes a biarch toolchain?

[Andreas Schwab]

Jan Dittmer <jdittmer@ppp0.net> writes:

> $ powerpc64-linux-gcc-4.0.4 -v
> Using built-in specs.
> Target: powerpc64-linux
> Configured with: ../configure --prefix=/usr/cc217
> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
> --disable-shared --disable-werror --disable-nls --disable-threads
> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
> --with-gnu-ld --enable-languages=c
> Thread model: single
> gcc version 4.0.4
>
> g5_defconfig:
>
> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- 
> CROSS32_COMPILE=powerpc64-linux-

Your compiler still needs -m32 to generate 32-bit code (or use
--with-cpu=default32 to make that the default).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: boot/wrap assumes a biarch toolchain?

[Jan Dittmer]

Andreas Schwab wrote:
> Jan Dittmer <jdittmer@ppp0.net> writes:
> 
>> $ powerpc64-linux-gcc-4.0.4 -v
>> Using built-in specs.
>> Target: powerpc64-linux
>> Configured with: ../configure --prefix=/usr/cc217
>> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
>> --disable-shared --disable-werror --disable-nls --disable-threads
>> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
>> --with-gnu-ld --enable-languages=c
>> Thread model: single
>> gcc version 4.0.4
>>
>> g5_defconfig:
>>
>> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- 
>> CROSS32_COMPILE=powerpc64-linux-
> 
> Your compiler still needs -m32 to generate 32-bit code (or use
> --with-cpu=default32 to make that the default).

4.1.2 exhibits the same behavior. When did it start to work without
additional options? 4.2?

Jan

Re: boot/wrap assumes a biarch toolchain?

[Andreas Schwab]

Jan Dittmer <jdi@l4x.org> writes:

> Andreas Schwab wrote:
>> Jan Dittmer <jdittmer@ppp0.net> writes:
>>
>>> $ powerpc64-linux-gcc-4.0.4 -v
>>> Using built-in specs.
>>> Target: powerpc64-linux
>>> Configured with: ../configure --prefix=/usr/cc217
>>> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
>>> --disable-shared --disable-werror --disable-nls --disable-threads
>>> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
>>> --with-gnu-ld --enable-languages=c
>>> Thread model: single
>>> gcc version 4.0.4
>>>
>>> g5_defconfig:
>>>
>>> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- 
>>> CROSS32_COMPILE=powerpc64-linux-
>>
>> Your compiler still needs -m32 to generate 32-bit code (or use
>> --with-cpu=default32 to make that the default).
>
> 4.1.2 exhibits the same behavior.

What do you mean with "the same behavior"?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: boot/wrap assumes a biarch toolchain?

[Jan Dittmer]

Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
> 
>> Andreas Schwab wrote:
>>> Jan Dittmer <jdittmer@ppp0.net> writes:
>>>
>>>> $ powerpc64-linux-gcc-4.0.4 -v
>>>> Using built-in specs.
>>>> Target: powerpc64-linux
>>>> Configured with: ../configure --prefix=/usr/cc217
>>>> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
>>>> --disable-shared --disable-werror --disable-nls --disable-threads
>>>> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
>>>> --with-gnu-ld --enable-languages=c
>>>> Thread model: single
>>>> gcc version 4.0.4
>>>>
>>>> g5_defconfig:
>>>>
>>>> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux- 
>>>> CROSS32_COMPILE=powerpc64-linux-
>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>> --with-cpu=default32 to make that the default).
>> 4.1.2 exhibits the same behavior.
> 
> What do you mean with "the same behavior"?

Same error, you write above that a newer compiler version should
not need -m32 or --with-cpu=default32 any more? But I still get:

   CC      arch/powerpc/kernel/signal.o
   LDS     arch/powerpc/kernel/vdso32/vdso32.lds
   VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o
   VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S: 
Assembler messages:
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33: 
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33: 
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37: 
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37: 
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95: 
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95: 
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103: 
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103: 
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130: 
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130: 
Error: junk at end of line: `@local'
make[3]: *** [arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
make[2]: *** [arch/powerpc/kernel/vdso32] Error 2
make[1]: *** [arch/powerpc/kernel] Error 2
make: *** [sub-make] Error 2

Jan

> 
> Andreas.
> 

Re: boot/wrap assumes a biarch toolchain?

[Andreas Schwab]

Jan Dittmer <jdi@l4x.org> writes:

> Same error, you write above that a newer compiler version should
> not need -m32 or --with-cpu=default32 any more?

??? Where did I say that?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: boot/wrap assumes a biarch toolchain?

[Jan Dittmer]

Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
> 
>> Same error, you write above that a newer compiler version should
>> not need -m32 or --with-cpu=default32 any more?
> 
> ??? Where did I say that?

Your mail from 2007-10-29 4:39 pm (CET)

 >> Your compiler still needs -m32 to generate 32-bit code (or use
 >> --with-cpu=default32 to make that the default).

See the 'still' ? I just assumed that it must have been changed
in newer versions.

But to sum up. I've to compile with '--with-cpu=default32' and all
should be fine? Because I have no idea how to pass the -m32 flag
just to the 32-bit code generation. Passing it via CFLAGS obviously
does not work as it also passes it to the 64 bit code generation.

Jan

Re: boot/wrap assumes a biarch toolchain?

[Andreas Schwab]

Jan Dittmer <jdi@l4x.org> writes:

> Your mail from 2007-10-29 4:39 pm (CET)
>
>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>> --with-cpu=default32 to make that the default).
>
> See the 'still' ?

How would the compiler know whether to generate 64bit or 32bit code??

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: boot/wrap assumes a biarch toolchain?

[Jan Dittmer]

Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
> 
>> Your mail from 2007-10-29 4:39 pm (CET)
>>
>>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>>> --with-cpu=default32 to make that the default).
>> See the 'still' ?
> 
> How would the compiler know whether to generate 64bit or 32bit code??

Andreas, I think we both got a bit lost. Lets take a step back.

The original problem was that after 2.6.23 cross compiling
powerpc/g5_defconfig broke (Regression). Using gcc 4.0.4, powerpc64
target as cross compiler and powerpc target as 32-bit cross compiler.

Since 2.6.23-git1 it is now broken. Using gcc 4.1.2 didn't fix this. Neither
with "--with-cpu=default32" present nor without. So could you please
explain to me how I'm supposed to cross compile powerpc/g5_defconfig now?
Passing CFLAGS=-m32 didn't help too.

Or is it just a new bug in the kernel make system?

Just for reference up till 2.6.23 I used the following command:
make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux-  \
	CROSS32_COMPILE=powerpc-linux-

Thanks,

Jan

Re: boot/wrap assumes a biarch toolchain?

[Jan Dittmer]

Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
> 
>> Your mail from 2007-10-29 4:39 pm (CET)
>>
>>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>>> --with-cpu=default32 to make that the default).
>> See the 'still' ?
> 
> How would the compiler know whether to generate 64bit or 32bit code??

... and it works again with .24-rc1-git6. So whatever the problem
was. Consider it resolved.

Jan