fix typo in binutils version check

Olaf Hering wrote:
| The binutils check is bogus, it doesnt work with the just released | binutils.

why is this check bogus then? i tried to compile a kernel with some recent binutils which didn't pass the test - compilation failed. H.J.Lu's binutils [1] are working quite well, the releases from redhat
[2] seem to produce these results you wrote about.

Quoted 5 lines · Christian Kujau

Olaf Hering wrote:
| The binutils check is bogus, it doesnt work with the just released | binutils.

Quoted 4 lines

why is this check bogus then? i tried to compile a kernel with some recent binutils which didn't pass the test - compilation failed. H.J.Lu's binutils [1] are working quite well, the releases from redhat
[2] seem to produce these results you wrote about.

The checkbin target fails with current binutils cvs, you need an additional option like -many

pomegranate:~# echo dssall | /usr/bin/as -o /tmp/x
{standard input}: Assembler messages:
{standard input}:1: Error: Unrecognized opcode: `dssall'
pomegranate:~# /usr/bin/as -v
GNU assembler version 2.15.91.0.1 (powerpc-suse-linux) using BFD version 2.15.91.0.1 20040527 (SuSE Linux)

*** 2.6 kernels no longer buildcorrectly with old versions of binutils. *** Please upgrade your binutils to 2.12.1 or newer
make: *** [checkbin] Error 1
make: Target `all' not remade because of errors.

Quoted 7 lines · Olaf Hering

pomegranate:~# echo dssall | /usr/bin/as -o /tmp/x
{standard input}: Assembler messages:
{standard input}:1: Error: Unrecognized opcode: `dssall'
pomegranate:~# /usr/bin/as -v
GNU assembler version 2.15.91.0.1 (powerpc-suse-linux) using BFD version 2.15.91.0.1 20040527 (SuSE Linux)

Quoted 4 lines

*** 2.6 kernels no longer buildcorrectly with old versions of binutils. *** Please upgrade your binutils to 2.12.1 or newer
make: *** [checkbin] Error 1
make: Target `all' not remade because of errors.

I talked to Alan, and -many is the correct fix.

Quoted 15 lines · Olaf Hering

Quoted 11 lines · Olaf Hering

pomegranate:~# echo dssall | /usr/bin/as -o /tmp/x
{standard input}: Assembler messages:
{standard input}:1: Error: Unrecognized opcode: `dssall'
pomegranate:~# /usr/bin/as -v
GNU assembler version 2.15.91.0.1 (powerpc-suse-linux) using BFD version 2.15.91.0.1 20040527 (SuSE Linux)

*** 2.6 kernels no longer buildcorrectly with old versions of binutils. *** Please upgrade your binutils to 2.12.1 or newer
make: *** [checkbin] Error 1
make: Target `all' not remade because of errors.

Quoted 1 line

I talked to Alan, and -many is the correct fix.

Does the resulting kernel compile (e.g. on a config where we might try and compile a .S file with 'dssall' in it) ? I could be missing it, but is -many passed down to gas by something else now? Otherwise this isn't a correct fix the assembler won't work. :)

Quoted 19 lines · Tom Rini

Quoted 16 lines · Olaf Hering

Quoted 11 lines · Olaf Hering

pomegranate:~# echo dssall | /usr/bin/as -o /tmp/x
{standard input}: Assembler messages:
{standard input}:1: Error: Unrecognized opcode: `dssall'
pomegranate:~# /usr/bin/as -v
GNU assembler version 2.15.91.0.1 (powerpc-suse-linux) using BFD version 2.15.91.0.1 20040527 (SuSE Linux)

*** 2.6 kernels no longer buildcorrectly with old versions of binutils. *** Please upgrade your binutils to 2.12.1 or newer
make: *** [checkbin] Error 1
make: Target `all' not remade because of errors.

I talked to Alan, and -many is the correct fix.

Quoted 4 lines

Does the resulting kernel compile (e.g. on a config where we might try and compile a .S file with 'dssall' in it) ? I could be missing it, but is -many passed down to gas by something else now? Otherwise this isn't a correct fix the assembler won't work. :)

Everyone who wants to build the latest and greatest kernel can also update binutils, its a no-brainer.

Quoted 2 lines

Everyone who wants to build the latest and greatest kernel can also update binutils, its a no-brainer.

... which does, or doesn't compile a kernel? Does the latest and greatest binutils and gcc automatically pass down -many, or does it fail to compile because the assembler needs -many, but it's not being passed along. That's what I asked.

And everyone who wants to build the latest and greatest stable kernel should probably stick with a stable release of binutils and gcc. But that's just my 2 cents. :)

Quoted 3 lines · Tom Rini

Quoted 2 lines

Everyone who wants to build the latest and greatest kernel can also update binutils, its a no-brainer.

Quoted 4 lines

... which does, or doesn't compile a kernel? Does the latest and greatest binutils and gcc automatically pass down -many, or does it fail to compile because the assembler needs -many, but it's not being passed along. That's what I asked.

plain gcc 3.2.3 + binutils 2.15.91.0.1 is a challenge, because it passes -mppc instead of -many.

Quoted 6 lines · Olaf Hering

Quoted 3 lines · Tom Rini

Quoted 2 lines

Everyone who wants to build the latest and greatest kernel can also update binutils, its a no-brainer.

Quoted 7 lines

Quoted 4 lines

... which does, or doesn't compile a kernel? Does the latest and greatest binutils and gcc automatically pass down -many, or does it fail to compile because the assembler needs -many, but it's not being passed along. That's what I asked.

plain gcc 3.2.3 + binutils 2.15.91.0.1 is a challenge, because it passes -mppc instead of -many.

We should fix it like that:

diff -purN linux-2.6.7-rc3-bk6.orig/arch/ppc/Makefile linux-2.6.7-rc3-bk6/arch/ppc/Makefile

... except that we can have 'dssall' even when CONFIG_ALTIVEC=n, so we need it really on CONFIG_6xx.

But more importantly, why did you break the check to stop people with broken binutils from trying to compile the kernel, and not fix the rest of the breakage ?

Quoted 2 lines · Tom Rini

... except that we can have 'dssall' even when CONFIG_ALTIVEC=n, so we need it really on CONFIG_6xx.

switch_mm() has it in CONFIG_ALTIVEC, so checking for CONFIG_ALTIVEC=y looks correct to me.

Quoted 3 lines

But more importantly, why did you break the check to stop people with broken binutils from trying to compile the kernel, and not fix the rest of the breakage ?

What exactly is broken in the old binutils?

Quoted 2 lines · Olaf Hering

On Mon, Jun 14, Tom Rini wrote:

Quoted 5 lines

Quoted 2 lines

... except that we can have 'dssall' even when CONFIG_ALTIVEC=n, so we need it really on CONFIG_6xx.

switch_mm() has it in CONFIG_ALTIVEC, so checking for CONFIG_ALTIVEC=y looks correct to me.

arch/ppc/kernel/l2cr.S unconditionally has 'dssall', and this file is compiled on all CONFIG_6xx builds.

Quoted 5 lines

Quoted 3 lines

But more importantly, why did you break the check to stop people with broken binutils from trying to compile the kernel, and not fix the rest of the breakage ?

What exactly is broken in the old binutils?

They do not understand 'dssall' (and a few other) instructions. So in 2.4 we didn't call them directly, but had something along the lines of:
#ifndef DSSALL
#define DSSALL 0x........
#endif

Using dssall was just a choice of convenience.

Quoted 7 lines · Tom Rini

Quoted 5 lines · Olaf Hering

Quoted 2 lines · Tom Rini

... except that we can have 'dssall' even when CONFIG_ALTIVEC=n, so we need it really on CONFIG_6xx.

Quoted 5 lines

Quoted 2 lines

switch_mm() has it in CONFIG_ALTIVEC, so checking for CONFIG_ALTIVEC=y looks correct to me.

arch/ppc/kernel/l2cr.S unconditionally has 'dssall', and this file is compiled on all CONFIG_6xx builds.

This l2cr.S change is not on kernel.org at least, so I did not find it.

So what additional patch do you suggest?

Quoted 12 lines

Quoted 5 lines

Quoted 3 lines

But more importantly, why did you break the check to stop people with broken binutils from trying to compile the kernel, and not fix the rest of the breakage ?

What exactly is broken in the old binutils?

They do not understand 'dssall' (and a few other) instructions. So in 2.4 we didn't call them directly, but had something along the lines of:
#ifndef DSSALL
#define DSSALL 0x........
#endif

Quoted 1 line

Using dssall was just a choice of convenience.

Ok, I think the check will still trigger with old binutils even with -many. Unless -many is a new option for as.

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

Quoted 3 lines · Tom Rini

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

gcc 3.2 passes only -mppc, so all altive instructions will fail to compile without either -many or -maltivec

Quoted 8 lines · Olaf Hering

Quoted 3 lines · Tom Rini

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

Quoted 2 lines

gcc 3.2 passes only -mppc, so all altive instructions will fail to compile without either -many or -maltivec

Are there altivec instructions when CONFIG_ALTIVEC is not set?

Quoted 9 lines

ifdef CONFIG_4xx
EXTRA_AFLAGS := -Wa,-m405
endif

arch/ppc/kernel/Makefile +3 -0

+ifdef CONFIG_6xx
+EXTRA_AFLAGS		:= -Wa,-maltivec
+endif

ifdef CONFIG_E500
EXTRA_AFLAGS := -Wa,-me500
endif

So, shouldn't this be "ifdef CONFIG_ALTIVEC" ?

Quoted 6 lines · Stef Simoens

Quoted 5 lines · Olaf Hering

Quoted 3 lines · Tom Rini

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

Quoted 4 lines

Quoted 2 lines

gcc 3.2 passes only -mppc, so all altive instructions will fail to compile without either -many or -maltivec

Are there altivec instructions when CONFIG_ALTIVEC is not set?

Yes. And I can forsee in the future were we might have BookE specific ones in the same situation.

Perhaps it makes sense to add a directive to the assembler to switch on the
fly, cfr. the `.chip' directive on m68k? E.g. using

    .chip 68040

we switch to 68040 mode, and using

    .chip 68k

we switch back to generic mode. That way we can have instructions for different
CPU types in the same kernel, while the assembler still checks the validity
depending on the selected CPU type.

Quoted 11 lines · Geert Uytterhoeven

Perhaps it makes sense to add a directive to the assembler to switch on the
fly, cfr. the `.chip' directive on m68k? E.g. using

   .chip 68040

we switch to 68040 mode, and using

   .chip 68k

Quoted 5 lines

we switch back to generic mode. That way we can have instructions for different
CPU types in the same kernel, while the assembler still checks the validity
depending on the selected CPU type.

That's come up before, and iirc Alan Modra said the support isn't there now for PPC and is relatively low on the priority list (but is on it).

Quoted 18 lines · Hollis Blanchard

Quoted 16 lines · Geert Uytterhoeven

Perhaps it makes sense to add a directive to the assembler to switch on the
fly, cfr. the `.chip' directive on m68k? E.g. using

   .chip 68040

we switch to 68040 mode, and using

   .chip 68k

we switch back to generic mode. That way we can have instructions for different
CPU types in the same kernel, while the assembler still checks the validity
depending on the selected CPU type.

Quoted 2 lines

That's come up before, and iirc Alan Modra said the support isn't there now for PPC and is relatively low on the priority list (but is on it).

Implemented 2003-11-22 for ppc. Even documented. :-)

But working in what versions of binutils ?

On Mon, Jul 26, 2004 at 12:36:52PM -0700, Tom Rini wrote:
[about ppc .machine]

Quoted 1 line

But working in what versions of binutils ?

HJ's 2.14.90.0.8 and later, FSF 2.15 release.

Quoted 10 lines · Tom Rini

Quoted 9 lines · Stef Simoens

Quoted 7 lines · Olaf Hering

Quoted 3 lines · Tom Rini

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

gcc 3.2 passes only -mppc, so all altive instructions will fail to compile without either -many or -maltivec

Quoted 4 lines

Quoted 1 line

Are there altivec instructions when CONFIG_ALTIVEC is not set?

Yes. And I can forsee in the future were we might have BookE specific ones in the same situation.

Perhaps it makes sense to add a directive to the assembler to switch on the fly, cfr. the `.chip' directive on m68k? E.g. using

Quoted 3 lines · Tom Rini

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

gcc 3.2 passes only -mppc, so all altive instructions will fail to compile without either -many or -maltivec

I have tested this patch with
gcc 3.2.3 + binutils-2.15.91.0.1
gcc 3.3.4 + binutils-2.15.91.0.1
gcc 3.4.1 + binutils-2.15.91.0.1
gcc 3.2.3 + binutils-2.15
gcc 3.3.4 + binutils-2.15
gcc 3.4.1 + binutils-2.15

Quoted 10 lines · Olaf Hering

Quoted 3 lines · Tom Rini

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

gcc 3.2 passes only -mppc, so all altive instructions will fail to compile without either -many or -maltivec

Quoted 7 lines

I have tested this patch with
gcc 3.2.3 + binutils-2.15.91.0.1
gcc 3.3.4 + binutils-2.15.91.0.1
gcc 3.4.1 + binutils-2.15.91.0.1
gcc 3.2.3 + binutils-2.15
gcc 3.3.4 + binutils-2.15
gcc 3.4.1 + binutils-2.15

I meant to sent this version of the patch, really use -many also for the .S files.

Quoted 18 lines · Olaf Hering

Quoted 16 lines · Olaf Hering

Quoted 3 lines · Tom Rini

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

gcc 3.2 passes only -mppc, so all altive instructions will fail to compile without either -many or -maltivec

I have tested this patch with
gcc 3.2.3 + binutils-2.15.91.0.1
gcc 3.3.4 + binutils-2.15.91.0.1
gcc 3.4.1 + binutils-2.15.91.0.1
gcc 3.2.3 + binutils-2.15
gcc 3.3.4 + binutils-2.15
gcc 3.4.1 + binutils-2.15

Quoted 2 lines

I meant to sent this version of the patch, really use -many also for the .S files.

[snip]

Kumar, Matt, can you give the following a shot on e500 and 4xx please? This should fix Olaf's problem, and remove some workarounds for previous binutils changes of this nature (to get 'foo' instruction, now you must pass -mbar to the assembler):

OK. After giving this a whirl (after a NAK from Matt, privately), it looks like some versions of binutils don't make proper use of -many (in 2.14 it will override ppc_cpu, and PPC_OPCODE_ANY doesn't look to be used). So that brings us to the following patch. Olaf, can you please verify this still works for you? Paul, is this OK with you?

OK. After giving this a whirl (after a NAK from Matt, privately), it looks like some versions of binutils don't make proper use of -many (in 2.14 it will override ppc_cpu, and PPC_OPCODE_ANY doesn't look to be used). So that brings us to the following patch. Olaf, can you please verify this still works for you? Paul, is this OK with you?

Quoted 5 lines · Tom Rini

OK. After giving this a whirl (after a NAK from Matt, privately), it looks like some versions of binutils don't make proper use of -many (in 2.14 it will override ppc_cpu, and PPC_OPCODE_ANY doesn't look to be used). So that brings us to the following patch. Olaf, can you please verify this still works for you? Paul, is this OK with you?

This is not enough.
as needs -many (or at least -maltivec) unconditionally for binutils 2.15 gcc needs also -maltivec because -mppc seems to disable -maltivec again.

Quoted 11 lines · Olaf Hering

Quoted 5 lines · Tom Rini

OK. After giving this a whirl (after a NAK from Matt, privately), it looks like some versions of binutils don't make proper use of -many (in 2.14 it will override ppc_cpu, and PPC_OPCODE_ANY doesn't look to be used). So that brings us to the following patch. Olaf, can you please verify this still works for you? Paul, is this OK with you?

This is not enough.
as needs -many (or at least -maltivec) unconditionally for binutils 2.15 gcc needs also -maltivec because -mppc seems to disable -maltivec again.

Hmm. So with binutils 2.14, we need to do -many,-mppc as -many will zero out all previous flags. On binutils 2.15, -mppc always resets the cpu_flags, thus clearing out -many. -mppc64bridge, -me500 and -m405/etc all do the same. So far we end up being lucky, imho, that don't trip over this on !CONFIG_6xx. So while I'm not exactly happy we have to do this, the following is the least ugly fix for this:

+cflags-$(CONFIG_6xx) += -Wa,-maltivec

Quoted 1 line · Tom Rini

+cflags-$(CONFIG_6xx) += -Wa,-maltivec

That breaks gas 2.14 with gcc 3.4 or gcc 3.5, it passes -mppc, -many to as and leads to this error:

Quoted 2 lines · Olaf Hering

On Mon, Jul 12, Tom Rini wrote:

Quoted 4 lines

Quoted 1 line

+cflags-$(CONFIG_6xx) += -Wa,-maltivec

That breaks gas 2.14 with gcc 3.4 or gcc 3.5, it passes -mppc, -many to as and leads to this error:

Er, are you sure you got your patches right? Adding -Wa,-maltivec only, shouldn't cause -many to ever show up (and we don't want -many to ever show up, since it is broken on otherwise supported binutils combos).

Quoted 6 lines · Tom Rini

Quoted 4 lines · Olaf Hering

Quoted 1 line · Tom Rini

+cflags-$(CONFIG_6xx) += -Wa,-maltivec

Quoted 6 lines

Quoted 2 lines

That breaks gas 2.14 with gcc 3.4 or gcc 3.5, it passes -mppc, -many to as and leads to this error:

Er, are you sure you got your patches right? Adding -Wa,-maltivec only, shouldn't cause -many to ever show up (and we don't want -many to ever show up, since it is broken on otherwise supported binutils combos).

gcc passes it without asking.

OK. Perhaps gcc should be refusing to build with older binutils perhaps? It sounds like gcc-3.4 + binutils-2.14 or older won't work unless we ensure that any -mppc/altivec/etc type flags that gcc itself would pass, excluding -many, are re-passed by the kernel itself.

Quoted 4 lines · Tom Rini

OK. Perhaps gcc should be refusing to build with older binutils perhaps? It sounds like gcc-3.4 + binutils-2.14 or older won't work unless we ensure that any -mppc/altivec/etc type flags that gcc itself would pass, excluding -many, are re-passed by the kernel itself.

Its just the 2.14 + gcc 3.4 combo that does not work. binutils 2.12, 2.13 and 2.15 works ok with gcc 3.4.

Quoted 7 lines · Olaf Hering

Quoted 4 lines · Tom Rini

OK. Perhaps gcc should be refusing to build with older binutils perhaps? It sounds like gcc-3.4 + binutils-2.14 or older won't work unless we ensure that any -mppc/altivec/etc type flags that gcc itself would pass, excluding -many, are re-passed by the kernel itself.

Quoted 2 lines

Its just the 2.14 + gcc 3.4 combo that does not work. binutils 2.12, 2.13 and 2.15 works ok with gcc 3.4.

Does gcc not pass down -many with 2.12/2.13, or does -many actually work there?

Quoted 13 lines · Tom Rini

Quoted 9 lines · Olaf Hering

Quoted 4 lines · Tom Rini

OK. Perhaps gcc should be refusing to build with older binutils perhaps? It sounds like gcc-3.4 + binutils-2.14 or older won't work unless we ensure that any -mppc/altivec/etc type flags that gcc itself would pass, excluding -many, are re-passed by the kernel itself.

Its just the 2.14 + gcc 3.4 combo that does not work. binutils 2.12, 2.13 and 2.15 works ok with gcc 3.4.

Does gcc not pass down -many with 2.12/2.13, or does -many actually work there?

looks like gas 2.14 has different -many behaviour.

Quoted 8 lines · Tom Rini

Quoted 7 lines · Olaf Hering

Quoted 4 lines · Tom Rini

OK. Perhaps gcc should be refusing to build with older binutils perhaps? It sounds like gcc-3.4 + binutils-2.14 or older won't work unless we ensure that any -mppc/altivec/etc type flags that gcc itself would pass, excluding -many, are re-passed by the kernel itself.

Quoted 5 lines

Quoted 2 lines

Its just the 2.14 + gcc 3.4 combo that does not work. binutils 2.12, 2.13 and 2.15 works ok with gcc 3.4.

Does gcc not pass down -many with 2.12/2.13, or does -many actually work there?

arch/ppc/Makefile line 120

Quoted 5 lines · Tom Rini

arch/ppc/Makefile +2 -1

+BAD_GCC_AS	:= $(shell echo mftb 5 | $(AS) -mppc -many -o /dev/null 2>/dev/null 2>&1 && echo 0 || echo 1)
 
-ifneq ($(NEW_AS),0)
 checkbin:
+ifeq ($(GCC_VERSION)$(BAD_GCC_AS),03041)

How is this supposed to work? You get either 0 or 1.

Quoted 10 lines · Olaf Hering

Review

Quoted 5 lines · Tom Rini

(quoted diff) +2 -1

+BAD_GCC_AS	:= $(shell echo mftb 5 | $(AS) -mppc -many -o /dev/null 2>/dev/null 2>&1 && echo 0 || echo 1)
 
-ifneq ($(NEW_AS),0)
 checkbin:
+ifeq ($(GCC_VERSION)$(BAD_GCC_AS),03041)

How is this supposed to work? You get either 0 or 1.

OK. The intent was that GCC_VERSION is always run, which will give '0304' on gcc-3.4 (tested) and if the binutils test also fails it will always give '1'.

Review

Quoted 5 lines · Tom Rini

(quoted diff) +2 -1

+BAD_GCC_AS	:= $(shell echo mftb 5 | $(AS) -mppc -many -o /dev/null 2>/dev/null 2>&1 && echo 0 || echo 1)
 
-ifneq ($(NEW_AS),0)
 checkbin:
+ifeq ($(GCC_VERSION)$(BAD_GCC_AS),03041)

How is this supposed to work? You get either 0 or 1.

Quoted 3 lines · Tom Rini

And yes, passing -many does work on all older supported versions of binutils. So perhaps we should just add -Wa,-many to our cflags and be done with it now (and for future fixes of this sort).

gcc 3.2 passes only -mppc, so all altive instructions will fail to compile without either -many or -maltivec