[PATCH] fix typo in binutils version check

[PATCH] fix typo in binutils version check

[Olaf Hering]

The binutils check is bogus, it doesnt work with the just released
binutils. A space is needed in the error message.

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.


--- linux-2.6.7-rc2-bk5.orig/arch/ppc/Makefile	2004-06-05 09:31:28.000000000 +0200
+++ linux-2.6.7-rc2-bk5/arch/ppc/Makefile	2004-06-05 09:38:02.000000000 +0200
@@ -94,7 +94,7 @@ endif

 ifneq ($(NEW_AS),0)
 checkbin:
-	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build'
+	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build '
 	@echo 'correctly with old versions of binutils.'
 	@echo '*** Please upgrade your binutils to ${GOODVER} or newer'
 	@false


--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix typo in binutils version check

[Christian Kujau]

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.

Christian.

[1] http://www.kernel.org/pub/linux/devel/binutils/
[2] ftp://sources.redhat.com/pub/binutils/releases/
- --
BOFH excuse #208:

Your mail is being routed through Germany ... and they're censoring us.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix typo in binutils version check

[Olaf Hering]

 On Sat, Jun 05, Christian Kujau wrote:

>
> 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.

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

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix typo in binutils version check

[Christian Kujau]

Olaf Hering wrote:
|>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

...or i just stick to the hjl branch and everything works fine :)

- --
BOFH excuse #399:

We are a 100% Microsoft Shop.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix typo in binutils version check

[Tom Rini]

On Sat, Jun 05, 2004 at 01:11:35PM +0200, Olaf Hering wrote:
>
>  On Sat, Jun 05, Christian Kujau wrote:
>
> >
> > 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.
>
> The checkbin target fails with current binutils cvs, you need an
> additional option like -many

IMHO, binutils CVS is broken, and -many shouldn't be needed.  But that's
not the direction things are heading apparently.

But I believe that when Paul talked about this with some of the binutils
folks it was decided that we should add -many to the AFLAGS so the
kernel won't have to care about this.  So can you add -many to the
AFLAGS, and make the binutils check use $(AFLAGS) as well?  Thanks.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

[PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Sat, Jun 05, Olaf Hering wrote:

> 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.



diff -p -purN linux-2.6.7-rc3.orig/arch/ppc/Makefile linux-2.6.7-rc3/arch/ppc/Makefile
--- linux-2.6.7-rc3.orig/arch/ppc/Makefile	2004-06-08 09:10:00.000000000 +0200
+++ linux-2.6.7-rc3/arch/ppc/Makefile	2004-06-08 12:37:06.000000000 +0200
@@ -86,7 +86,7 @@ include/asm-$(ARCH)/offsets.h: arch/$(AR

 ifdef CONFIG_6xx
 # Ensure this is binutils 2.12.1 (or 2.12.90.0.7) or later
-NEW_AS	:= $(shell echo dssall | $(AS) -o /dev/null >/dev/null 2>&1 ; echo $$?)
+NEW_AS	:= $(shell echo dssall | $(AS) -many -o /dev/null >/dev/null 2>&1 ; echo $$?)
 GOODVER	:= 2.12.1
 else
 NEW_AS	:= 0
@@ -94,7 +94,7 @@ endif

 ifneq ($(NEW_AS),0)
 checkbin:
-	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build'
+	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build '
 	@echo 'correctly with old versions of binutils.'
 	@echo '*** Please upgrade your binutils to ${GOODVER} or newer'
 	@false

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Tue, Jun 08, 2004 at 01:25:56PM +0200, Olaf Hering wrote:

>
>  On Sat, Jun 05, Olaf Hering wrote:
>
> > 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.

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. :)

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Wed, Jun 09, Tom Rini wrote:

> On Tue, Jun 08, 2004 at 01:25:56PM +0200, Olaf Hering wrote:
>
> >
> >  On Sat, Jun 05, Olaf Hering wrote:
> >
> > > 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.
>
> 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.

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Mon, Jun 14, 2004 at 11:15:30AM +0200, Olaf Hering wrote:

>  On Wed, Jun 09, Tom Rini wrote:
>
> > On Tue, Jun 08, 2004 at 01:25:56PM +0200, Olaf Hering wrote:
> >
> > >
> > >  On Sat, Jun 05, Olaf Hering wrote:
> > >
> > > > 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.
> >
> > 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.

... 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. :)

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Mon, Jun 14, Tom Rini wrote:

> > 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.

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

> 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. :)

Lets just declare the hammer branch as stable, and older junk as
unstable.

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Mon, Jun 14, Olaf Hering wrote:

>
>  On Mon, Jun 14, Tom Rini wrote:
>
> > > 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.
>
> 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
--- linux-2.6.7-rc3-bk6.orig/arch/ppc/Makefile	2004-06-14 15:23:35.000000000 +0200
+++ linux-2.6.7-rc3-bk6/arch/ppc/Makefile	2004-06-14 19:46:25.336997085 +0200
@@ -22,6 +22,7 @@ CPP		= $(CC) -E $(CFLAGS)

 cflags-$(CONFIG_4xx)		+= -Wa,-m405
 cflags-$(CONFIG_PPC64BRIDGE)	+= -Wa,-mppc64bridge
+cflags-$(CONFIG_ALTIVEC)	+= -Wa,-maltivec

 CFLAGS += $(cflags-y)


--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Mon, Jun 14, 2004 at 08:07:34PM +0200, Olaf Hering wrote:

>  On Mon, Jun 14, Olaf Hering wrote:
>
> >
> >  On Mon, Jun 14, Tom Rini wrote:
> >
> > > > 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.
> >
> > 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
> --- linux-2.6.7-rc3-bk6.orig/arch/ppc/Makefile	2004-06-14 15:23:35.000000000 +0200
> +++ linux-2.6.7-rc3-bk6/arch/ppc/Makefile	2004-06-14 19:46:25.336997085 +0200
> @@ -22,6 +22,7 @@ CPP		= $(CC) -E $(CFLAGS)
>
>  cflags-$(CONFIG_4xx)		+= -Wa,-m405
>  cflags-$(CONFIG_PPC64BRIDGE)	+= -Wa,-mppc64bridge
> +cflags-$(CONFIG_ALTIVEC)	+= -Wa,-maltivec
>
>  CFLAGS += $(cflags-y)

... 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 ?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Mon, Jun 14, Tom Rini wrote:

> ... 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.

> 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?
Is it this one?
 opcodes/ChangeLog-0203
2002-04-17  matthew green  <mrg@redhat.com>
        * ppc-opc.c (powerpc_opcode): Fix dssall operand list.

Or rev 1.21 in opcodes/ppc-opc.c? The current check seems to check just
for that one.

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Mon, Jun 14, 2004 at 11:19:31PM +0200, Olaf Hering wrote:

>  On Mon, Jun 14, Tom Rini wrote:
>
> > ... 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.

> > 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.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Tue, Jun 15, Tom Rini wrote:

> On Mon, Jun 14, 2004 at 11:19:31PM +0200, Olaf Hering wrote:
>
> >  On Mon, Jun 14, Tom Rini wrote:
> >
> > > ... 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.

This l2cr.S change is not on kernel.org at least, so I did not find it.
So what additional patch do you suggest?

> > > 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.

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

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Tue, Jun 15, 2004 at 07:25:11PM +0200, Olaf Hering wrote:

>  On Tue, Jun 15, Tom Rini wrote:
>
> > On Mon, Jun 14, 2004 at 11:19:31PM +0200, Olaf Hering wrote:
> >
> > >  On Mon, Jun 14, Tom Rini wrote:
> > >
> > > > ... 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.
>
> This l2cr.S change is not on kernel.org at least, so I did not find it.

It most certainly is:
[trini@Bill-The-Cat ~/work/kernel/pristine/linux-2.5/arch/ppc/kernel]$
grep l2cr Makefile
obj-$(CONFIG_6xx)               += l2cr.o cpu_setup_6xx.o

> So what additional patch do you suggest?

Changing your patch from cflags-$(CONFIG_ALTIVEC) to
cflags-$(CONFIG_6xx).  Or always pass it (see below), or fix binutils :)

> > > > 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.
>
> Ok, I think the check will still trigger with old binutils even with
> -many. Unless -many is a new option for as.

*ahem*.  The problem is that given newer binutils requiring -many to
process altivec instructions, like dssall, and given that we include
altivec instructions in the ppc32 kernel and given that we don't
otherwise have something like -many, or -maltivec, why did you change the
check for a working binutils version, without changing things such that the
kernel will build with this new' version of binutils?

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).

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Tue, Jun 15, Tom Rini wrote:

> 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


diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.7-bk16.orig/arch/ppc/Makefile linux-2.6.7-bk16/arch/ppc/Makefile
--- linux-2.6.7-bk16.orig/arch/ppc/Makefile	2004-07-03 22:33:35.000000000 +0200
+++ linux-2.6.7-bk16/arch/ppc/Makefile	2004-07-03 23:11:10.037787069 +0200
@@ -24,6 +24,9 @@ ifndef CONFIG_E500
 cflags-y	+= -mstring
 endif

+# gcc 3.2.3 passes -mppc,
+# the altivec asm code will fail to compile with binutils newer than 2.15
+cflags-$(CONFIG_6xx)		+= -Wa,-many
 cflags-$(CONFIG_4xx)		+= -Wa,-m405
 cflags-$(CONFIG_E500)		+= -Wa,-me500
 cflags-$(CONFIG_PPC64BRIDGE)	+= -Wa,-mppc64bridge
diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.7-bk16.orig/arch/ppc/kernel/Makefile linux-2.6.7-bk16/arch/ppc/kernel/Makefile
--- linux-2.6.7-bk16.orig/arch/ppc/kernel/Makefile	2004-07-03 22:33:35.000000000 +0200
+++ linux-2.6.7-bk16/arch/ppc/kernel/Makefile	2004-07-03 22:51:16.802332774 +0200
@@ -8,6 +8,9 @@ endif
 ifdef CONFIG_4xx
 EXTRA_AFLAGS		:= -Wa,-m405
 endif
+ifdef CONFIG_6xx
+EXTRA_AFLAGS		:= -Wa,-maltivec
+endif
 ifdef CONFIG_E500
 EXTRA_AFLAGS		:= -Wa,-me500
 endif

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Stef Simoens]

Olaf Hering wrote:

>  On Tue, Jun 15, Tom Rini wrote:
>
>
>>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

Are there altivec instructions when CONFIG_ALTIVEC is not set?

> diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.7-bk16.orig/arch/ppc/kernel/Makefile linux-2.6.7-bk16/arch/ppc/kernel/Makefile
> --- linux-2.6.7-bk16.orig/arch/ppc/kernel/Makefile	2004-07-03 22:33:35.000000000 +0200
> +++ linux-2.6.7-bk16/arch/ppc/kernel/Makefile	2004-07-03 22:51:16.802332774 +0200
> @@ -8,6 +8,9 @@ endif
>  ifdef CONFIG_4xx
>  EXTRA_AFLAGS		:= -Wa,-m405
>  endif
> +ifdef CONFIG_6xx
> +EXTRA_AFLAGS		:= -Wa,-maltivec
> +endif
>  ifdef CONFIG_E500
>  EXTRA_AFLAGS		:= -Wa,-me500
>  endif

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

Stef


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Sun, Jul 04, 2004 at 03:30:47AM +0200, Stef Simoens wrote:

> Olaf Hering wrote:
>
> > On Tue, Jun 15, Tom Rini wrote:
> >
> >
> >>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
>
> 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.

> > ifdef CONFIG_4xx
> > EXTRA_AFLAGS		:= -Wa,-m405
> > endif
> >+ifdef CONFIG_6xx
> >+EXTRA_AFLAGS		:= -Wa,-maltivec
> >+endif
> > ifdef CONFIG_E500
> > EXTRA_AFLAGS		:= -Wa,-me500
> > endif
>
> So, shouldn't this be "ifdef CONFIG_ALTIVEC" ?

No, it should be always -Wa,-many.  The kernel has, and almost certainly
will, continue to put AltiVec, or BookE, or whatever, instructions in
code that will be compiled for, and run on, CPUs that can't use the
instructions (we nop them out at runtime).

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Sun, Jul 04, Olaf Hering wrote:

>
>  On Tue, Jun 15, Tom Rini wrote:
>
> > 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

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

diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.7-bk16.orig/arch/ppc/Makefile linux-2.6.7-bk16/arch/ppc/Makefile
--- linux-2.6.7-bk16.orig/arch/ppc/Makefile	2004-07-03 22:33:35.000000000 +0200
+++ linux-2.6.7-bk16/arch/ppc/Makefile	2004-07-03 23:11:10.037787069 +0200
@@ -24,6 +24,9 @@ ifndef CONFIG_E500
 cflags-y	+= -mstring
 endif

+# gcc 3.2.3 passes -mppc,
+# the altivec asm code will fail to compile with binutils newer than 2.15
+cflags-$(CONFIG_6xx)		+= -Wa,-many
 cflags-$(CONFIG_4xx)		+= -Wa,-m405
 cflags-$(CONFIG_E500)		+= -Wa,-me500
 cflags-$(CONFIG_PPC64BRIDGE)	+= -Wa,-mppc64bridge
diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.7-bk16.orig/arch/ppc/kernel/Makefile linux-2.6.7-bk16/arch/ppc/kernel/Makefile
--- linux-2.6.7-bk16.orig/arch/ppc/kernel/Makefile	2004-07-03 22:33:35.000000000 +0200
+++ linux-2.6.7-bk16/arch/ppc/kernel/Makefile	2004-07-03 22:51:16.802332774 +0200
@@ -8,6 +8,9 @@ endif
 ifdef CONFIG_4xx
 EXTRA_AFLAGS		:= -Wa,-m405
 endif
+ifdef CONFIG_6xx
+EXTRA_AFLAGS		:= -Wa,-many
+endif
 ifdef CONFIG_E500
 EXTRA_AFLAGS		:= -Wa,-me500
 endif

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Geert Uytterhoeven]

On Sat, 3 Jul 2004, Tom Rini wrote:
> On Sun, Jul 04, 2004 at 03:30:47AM +0200, Stef Simoens wrote:
> > Olaf Hering wrote:
> > > On Tue, Jun 15, Tom Rini wrote:
> > >>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
> >
> > 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.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Hollis Blanchard]

On Jul 4, 2004, at 3:32 AM, Geert Uytterhoeven wrote:
>
> 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.

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).

--
Hollis Blanchard
IBM Linux Technology Center


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Sun, Jul 04, 2004 at 10:32:52AM +0200, Geert Uytterhoeven wrote:

> On Sat, 3 Jul 2004, Tom Rini wrote:
> > On Sun, Jul 04, 2004 at 03:30:47AM +0200, Stef Simoens wrote:
> > > Olaf Hering wrote:
> > > > On Tue, Jun 15, Tom Rini wrote:
> > > >>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
> > >
> > > 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

AFAIK, the problem which caused the need for introducing -maltivec was
a problem with the disassembler and conflicting opcodes.  It should still
be able to check the validity of things with -many (I would hope..).

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Sun, Jul 04, 2004 at 12:29:18AM +0200, Olaf Hering wrote:

>  On Tue, Jun 15, Tom Rini wrote:
>
> > 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

Yes, this is a _binutils_ problem however, as older binutils (2.14.* and
lower that we would allow anyhow) are fine.

> diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.7-bk16.orig/arch/ppc/Makefile linux-2.6.7-bk16/arch/ppc/Makefile
> --- linux-2.6.7-bk16.orig/arch/ppc/Makefile	2004-07-03 22:33:35.000000000 +0200
> +++ linux-2.6.7-bk16/arch/ppc/Makefile	2004-07-03 23:11:10.037787069 +0200
> @@ -24,6 +24,9 @@ ifndef CONFIG_E500
>  cflags-y	+= -mstring
>  endif
>
> +# gcc 3.2.3 passes -mppc,
> +# the altivec asm code will fail to compile with binutils newer than 2.15
> +cflags-$(CONFIG_6xx)		+= -Wa,-many

No.  We _always_ want to pass in -Wa,-many to future-proof ourself from
this being a problem again.

> --- linux-2.6.7-bk16.orig/arch/ppc/kernel/Makefile	2004-07-03 22:33:35.000000000 +0200
> +++ linux-2.6.7-bk16/arch/ppc/kernel/Makefile	2004-07-03 22:51:16.802332774 +0200
> @@ -8,6 +8,9 @@ endif
>  ifdef CONFIG_4xx
>  EXTRA_AFLAGS		:= -Wa,-m405
>  endif
> +ifdef CONFIG_6xx
> +EXTRA_AFLAGS		:= -Wa,-maltivec
> +endif

And this should become redundant.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Sun, Jul 04, 2004 at 09:23:50AM +0200, Olaf Hering wrote:
>
>  On Sun, Jul 04, Olaf Hering wrote:
>
> >
> >  On Tue, Jun 15, Tom Rini wrote:
> >
> > > 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
>
> 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):

Signed-off-by: Tom Rini <trini@kernel.crashing.org>

===== arch/ppc/Makefile 1.54 vs edited =====
--- 1.54/arch/ppc/Makefile	2004-06-26 14:10:12 -07:00
+++ edited/arch/ppc/Makefile	2004-07-05 11:27:18 -07:00
@@ -15,17 +15,15 @@

 LDFLAGS_vmlinux	:= -Ttext $(KERNELLOAD) -Bstatic
 CPPFLAGS	+= -Iarch/$(ARCH)
-AFLAGS		+= -Iarch/$(ARCH)
+AFLAGS		+= -Iarch/$(ARCH) -Wa,-many
 cflags-y	+= -Iarch/$(ARCH) -msoft-float -pipe \
-		-ffixed-r2 -Wno-uninitialized -mmultiple
+		-ffixed-r2 -Wno-uninitialized -mmultiple -Wa,-many
 CPP		= $(CC) -E $(CFLAGS)

 ifndef CONFIG_E500
 cflags-y	+= -mstring
 endif

-cflags-$(CONFIG_4xx)		+= -Wa,-m405
-cflags-$(CONFIG_E500)		+= -Wa,-me500
 cflags-$(CONFIG_PPC64BRIDGE)	+= -Wa,-mppc64bridge

 CFLAGS += $(cflags-y)
===== arch/ppc/kernel/Makefile 1.47 vs edited =====
--- 1.47/arch/ppc/kernel/Makefile	2004-06-17 23:41:08 -07:00
+++ edited/arch/ppc/kernel/Makefile	2004-07-05 11:27:22 -07:00
@@ -5,12 +5,6 @@
 ifdef CONFIG_PPC64BRIDGE
 EXTRA_AFLAGS		:= -Wa,-mppc64bridge
 endif
-ifdef CONFIG_4xx
-EXTRA_AFLAGS		:= -Wa,-m405
-endif
-ifdef CONFIG_E500
-EXTRA_AFLAGS		:= -Wa,-me500
-endif

 extra-$(CONFIG_PPC_STD_MMU)	:= head.o
 extra-$(CONFIG_40x)		:= head_4xx.o

If this does take care of everything, Paul, is this OK with you?
(and it might also remove the need for the -mppc64bridge bit, if
you'd like to test that. :))

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Mon, Jul 05, 2004 at 11:32:19AM -0700, Tom Rini wrote:
> On Sun, Jul 04, 2004 at 09:23:50AM +0200, Olaf Hering wrote:
> >  On Sun, Jul 04, Olaf Hering wrote:
> > >  On Tue, Jun 15, Tom Rini wrote:
> > >
> > > > 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
> >
> > 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?

Signed-off-by: Tom Rini <trini@kernel.crashing.org>

===== arch/ppc/Makefile 1.78 vs edited =====
--- 1.78/arch/ppc/Makefile	2004-07-08 16:04:11 -07:00
+++ edited/arch/ppc/Makefile	2004-07-08 18:32:17 -07:00
@@ -23,7 +23,7 @@
 LDFLAGS_vmlinux	:= -Ttext $(KERNELLOAD) -Bstatic
 CPPFLAGS	+= -Iarch/$(ARCH)
 AFLAGS		+= -Iarch/$(ARCH)
-cflags-y	+= -Iarch/$(ARCH) -msoft-float -pipe \
+cflags-y	+= -Iarch/$(ARCH) -msoft-float -pipe -Wa,-many,-mppc \
 		-ffixed-r2 -Wno-uninitialized -mmultiple
 CPP		= $(CC) -E $(CFLAGS)


--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Thu, Jul 08, 2004 at 06:34:29PM -0700, Tom Rini wrote:
[snip]
> 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?

The other alternative, if we want to try and rely on -many working w/o
other flags passed is to depend on binutils-2.15* or newer.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Thu, Jul 08, Tom Rini wrote:

> 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.

I'm rerunning my script right now, with this patch.


diff -purNX /suse/olh/kernel/kernel_exclude.txt linux-2.6.8-rc1.orig/arch/ppc/Makefile linux-2.6.8-rc1/arch/ppc/Makefile
--- linux-2.6.8-rc1.orig/arch/ppc/Makefile	2004-07-12 08:02:54.000000000 +0200
+++ linux-2.6.8-rc1/arch/ppc/Makefile	2004-07-12 10:48:34.838426125 +0200
@@ -22,8 +22,8 @@ endif

 LDFLAGS_vmlinux	:= -Ttext $(KERNELLOAD) -Bstatic
 CPPFLAGS	+= -Iarch/$(ARCH)
-AFLAGS		+= -Iarch/$(ARCH)
-cflags-y	+= -Iarch/$(ARCH) -msoft-float -pipe \
+AFLAGS		+= -Iarch/$(ARCH) -Wa,-many
+cflags-y	+= -Iarch/$(ARCH) -msoft-float -pipe -Wa,-many,-mppc,-maltivec \
 		-ffixed-r2 -Wno-uninitialized -mmultiple
 CPP		= $(CC) -E $(CFLAGS)


--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Mon, Jul 12, 2004 at 11:06:18AM +0200, Olaf Hering wrote:
>  On Thu, Jul 08, Tom Rini wrote:
>
> > 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:

Signed-off-by: Tom Rini <trini@kernel.crashing.org>

--- 1.55/arch/ppc/Makefile	2004-07-05 03:27:10 -07:00
+++ edited//home/trini/work/kernel/pristine/linux-2.6/arch/ppc/Makefile	2004-07-12 08:10:10 -07:00
@@ -32,6 +32,7 @@
 endif

 cflags-$(CONFIG_4xx)		+= -Wa,-m405
+cflags-$(CONFIG_6xx)		+= -Wa,-maltivec
 cflags-$(CONFIG_E500)		+= -Wa,-me500
 cflags-$(CONFIG_PPC64BRIDGE)	+= -Wa,-mppc64bridge


--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Mon, Jul 12, 2004 at 08:11:19AM -0700, Tom Rini wrote:

>
> On Mon, Jul 12, 2004 at 11:06:18AM +0200, Olaf Hering wrote:
> >  On Thu, Jul 08, Tom Rini wrote:
> >
> > > 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:

Lets try the following, which does a few other cleanups, in addition to
fixing AFLAGS.

Signed-off-by: Tom Rini <trini@kernel.crashing.org>

--- 1.55/arch/ppc/Makefile	2004-07-05 03:27:10 -07:00
+++ edited/arch/ppc/Makefile	2004-07-12 08:21:35 -07:00
@@ -22,7 +22,7 @@

 LDFLAGS_vmlinux	:= -Ttext $(KERNELLOAD) -Bstatic
 CPPFLAGS	+= -Iarch/$(ARCH)
-AFLAGS		+= -Iarch/$(ARCH)
+aflags-y	+= -Iarch/$(ARCH)
 cflags-y	+= -Iarch/$(ARCH) -msoft-float -pipe \
 		-ffixed-r2 -Wno-uninitialized -mmultiple
 CPP		= $(CC) -E $(CFLAGS)
@@ -31,10 +31,16 @@
 cflags-y	+= -mstring
 endif

+aflags-$(CONFIG_4xx)		+= -m405
 cflags-$(CONFIG_4xx)		+= -Wa,-m405
+aflags-$(CONFIG_6xx)		+= -maltivec
+cflags-$(CONFIG_6xx)		+= -Wa,-maltivec
+aflags-$(CONFIG_E500)		+= -me500
 cflags-$(CONFIG_E500)		+= -Wa,-me500
+aflags-$(CONFIG_PPC64BRIDGE)	+= -mppc64bridge
 cflags-$(CONFIG_PPC64BRIDGE)	+= -Wa,-mppc64bridge

+AFLAGS += $(aflags-y)
 CFLAGS += $(cflags-y)

 head-y				:= arch/ppc/kernel/head.o
--- 1.47/arch/ppc/kernel/Makefile	2004-06-17 23:41:08 -07:00
+++ edited/arch/ppc/kernel/Makefile	2004-07-12 08:22:12 -07:00
@@ -2,16 +2,6 @@
 # Makefile for the linux kernel.
 #

-ifdef CONFIG_PPC64BRIDGE
-EXTRA_AFLAGS		:= -Wa,-mppc64bridge
-endif
-ifdef CONFIG_4xx
-EXTRA_AFLAGS		:= -Wa,-m405
-endif
-ifdef CONFIG_E500
-EXTRA_AFLAGS		:= -Wa,-me500
-endif
-
 extra-$(CONFIG_PPC_STD_MMU)	:= head.o
 extra-$(CONFIG_40x)		:= head_4xx.o
 extra-$(CONFIG_44x)		:= head_44x.o
@@ -35,7 +25,5 @@
 obj-$(CONFIG_TAU)		+= temp.o
 obj-$(CONFIG_ALTIVEC)		+= vecemu.o vector.o

-ifdef CONFIG_MATH_EMULATION
-obj-$(CONFIG_8xx)		+= softemu8xx.o
-endif
-
+sw-math-emu-$(CONFIG_8xx)	+= softemu8xx.o
+obj-$(CONFIG_MATH_EMULATION)	+= $(sw-math-emu-y)
--- 1.17/arch/ppc/mm/Makefile	2004-06-17 23:41:08 -07:00
+++ edited/arch/ppc/mm/Makefile	2004-07-12 08:22:21 -07:00
@@ -2,10 +2,6 @@
 # Makefile for the linux ppc-specific parts of the memory manager.
 #

-ifdef CONFIG_PPC64BRIDGE
-EXTRA_AFLAGS		:= -Wa,-mppc64bridge
-endif
-
 obj-y				:= fault.o init.o mem_pieces.o \
 					mmu_context.o pgtable.o

--- 1.31/arch/ppc/platforms/Makefile	2004-06-16 11:22:35 -07:00
+++ edited/arch/ppc/platforms/Makefile	2004-07-12 08:22:27 -07:00
@@ -2,29 +2,23 @@
 # Makefile for the linux kernel.
 #

-ifdef CONFIG_PPC64BRIDGE
-EXTRA_AFLAGS		:= -Wa,-mppc64bridge
-endif
-ifdef CONFIG_40x
-EXTRA_AFLAGS		:= -Wa,-m405
-endif
-
 # Extra CFLAGS so we don't have to do relative includes
 CFLAGS_pmac_setup.o	+= -Iarch/$(ARCH)/mm

-obj-$(CONFIG_APUS)		+= apus_setup.o
-ifeq ($(CONFIG_APUS),y)
-obj-$(CONFIG_PCI)		+= apus_pci.o
-endif
+# Multiple dependancies
+apus-$(CONFIG_PCI)		+= apus_pci.o
+chrp-$(CONFIG_SMP)		+= chrp_smp.o
+pmac-$(CONFIG_NVRAM)		+= pmac_nvram.o
+pmac-$(CONFIG_CPU_FREQ_PMAC)	+= pmac_cpufreq.o
+pmac-$(CONFIG_SMP)		+= pmac_smp.o
+
+obj-$(CONFIG_APUS)		+= apus_setup.o $(apus-y)
 obj-$(CONFIG_PPC_PMAC)		+= pmac_pic.o pmac_setup.o pmac_time.o \
 					pmac_feature.o pmac_pci.o pmac_sleep.o \
-					pmac_low_i2c.o
-obj-$(CONFIG_PPC_CHRP)		+= chrp_setup.o chrp_time.o chrp_pci.o
+					pmac_low_i2c.o $(pmac-y)
+obj-$(CONFIG_PPC_CHRP)		+= chrp_setup.o chrp_time.o chrp_pci.o \
+					$(chrp-y)
 obj-$(CONFIG_PPC_PREP)		+= prep_pci.o prep_setup.o
-ifeq ($(CONFIG_PPC_PMAC),y)
-obj-$(CONFIG_NVRAM)		+= pmac_nvram.o
-obj-$(CONFIG_CPU_FREQ_PMAC)	+= pmac_cpufreq.o
-endif
 obj-$(CONFIG_PMAC_BACKLIGHT)	+= pmac_backlight.o
 obj-$(CONFIG_PPC_RTAS)		+= error_log.o proc_rtas.o
 obj-$(CONFIG_PREP_RESIDUAL)	+= residual.o
@@ -48,8 +42,3 @@
 obj-$(CONFIG_SANDPOINT)		+= sandpoint.o
 obj-$(CONFIG_SBC82xx)		+= sbc82xx.o
 obj-$(CONFIG_SPRUCE)		+= spruce.o
-
-ifeq ($(CONFIG_SMP),y)
-obj-$(CONFIG_PPC_PMAC)		+= pmac_smp.o
-obj-$(CONFIG_PPC_CHRP)		+= chrp_smp.o
-endif
--- 1.3/arch/ppc/platforms/tqm8260_setup.c	2004-06-16 10:56:13 -07:00
+++ edited/arch/ppc/platforms/tqm8260_setup.c	2004-07-12 08:17:30 -07:00
@@ -77,3 +77,4 @@

 	callback_setup_arch	= ppc_md.setup_arch;
 	ppc_md.setup_arch	= tqm8260_setup_arch;
+}
--- 1.29/arch/ppc/syslib/Makefile	2004-07-01 22:23:46 -07:00
+++ edited/arch/ppc/syslib/Makefile	2004-07-12 08:22:30 -07:00
@@ -2,39 +2,27 @@
 # Makefile for the linux kernel.
 #

-ifdef CONFIG_PPC64BRIDGE
-EXTRA_AFLAGS		:= -Wa,-mppc64bridge
-endif
-ifdef CONFIG_4xx
-EXTRA_AFLAGS		:= -Wa,-m405
-endif
-ifdef CONFIG_E500
-EXTRA_AFLAGS		:= -Wa,-me500
-endif
-
 CFLAGS_prom_init.o      += -fPIC
 CFLAGS_btext.o          += -fPIC

+# Multiple dependancies
+ibm-4xx-$(CONFIG_GEN_RTC)	+= todc_time.o
+ibm-4xx-$(CONFIG_KGDB)		+= ppc4xx_kgdb.o
+ibm-40x-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o ppc405_pci.o
+mpc-8xx-$(CONFIG_PCI)		+= qspan_pci.o i8259.o
+gen550-$(CONFIG_KGDB)		+= gen550_kgdb.o gen550_dbg.o
+gen550-$(CONFIG_SERIAL_TEXT_DEBUG)	+= gen550_dbg.o
+mpc-85xx-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o
+
 obj-$(CONFIG_PPCBUG_NVRAM)	+= prep_nvram.o
 obj-$(CONFIG_PPC_OCP)		+= ocp.o
 obj-$(CONFIG_IBM_OCP)		+= ibm_ocp.o
 obj-$(CONFIG_44x)		+= ibm44x_common.o
 obj-$(CONFIG_440GP)		+= ibm440gp_common.o
 obj-$(CONFIG_440GX)		+= ibm440gx_common.o
-ifeq ($(CONFIG_4xx),y)
-obj-$(CONFIG_4xx)		+= ppc4xx_pic.o
-obj-$(CONFIG_40x)		+= ppc4xx_setup.o
-obj-$(CONFIG_GEN_RTC)		+= todc_time.o
-obj-$(CONFIG_KGDB)		+= ppc4xx_kgdb.o
-ifeq ($(CONFIG_40x),y)
-obj-$(CONFIG_KGDB)		+= ppc4xx_kgdb.o
-obj-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o ppc405_pci.o
-endif
-endif
-obj-$(CONFIG_8xx)		+= m8xx_setup.o ppc8xx_pic.o
-ifeq ($(CONFIG_8xx),y)
-obj-$(CONFIG_PCI)		+= qspan_pci.o i8259.o
-endif
+obj-$(CONFIG_4xx)		+= ppc4xx_pic.o $(ibm-4xx-y)
+obj-$(CONFIG_40x)		+= ppc4xx_setup.o $(ibm-40x-y)
+obj-$(CONFIG_8xx)		+= m8xx_setup.o ppc8xx_pic.o $(mpc-8xx-y)
 obj-$(CONFIG_PPC_OF)		+= prom_init.o prom.o of_device.o
 obj-$(CONFIG_PPC_PMAC)		+= open_pic.o indirect_pci.o
 obj-$(CONFIG_POWER4)		+= open_pic2.o
@@ -73,16 +61,11 @@
 obj-$(CONFIG_PCI_8260)		+= m8260_pci.o indirect_pci.o
 obj-$(CONFIG_8260_PCI9)		+= m8260_pci_erratum9.o
 obj-$(CONFIG_CPM2)		+= cpm2_common.o
-ifeq ($(CONFIG_PPC_GEN550),y)
-obj-$(CONFIG_KGDB)		+= gen550_kgdb.o gen550_dbg.o
-obj-$(CONFIG_SERIAL_TEXT_DEBUG)	+= gen550_dbg.o
-endif
+obj-$(CONFIG_PPC_GEN550)	+= $(gen550-y)
 obj-$(CONFIG_BOOTX_TEXT)	+= btext.o
 obj-$(CONFIG_MPC10X_BRIDGE)     += mpc10x_common.o indirect_pci.o
 obj-$(CONFIG_MPC10X_OPENPIC)	+= open_pic.o
 obj-$(CONFIG_40x)		+= dcr.o
 obj-$(CONFIG_BOOKE)		+= dcr.o
-obj-$(CONFIG_85xx)		+= open_pic.o ppc85xx_common.o ppc85xx_setup.o
-ifeq ($(CONFIG_85xx),y)
-obj-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o
-endif
+obj-$(CONFIG_85xx)		+= open_pic.o ppc85xx_common.o ppc85xx_setup.o \
+					$(mpc-85xx-y)

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Mon, Jul 12, Tom Rini wrote:

> +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:

 /home/olaf/toolchain/inst/binutils-2.14-gcc-3.4.1/lib/gcc/powerpc-unknown-linux-gnu/3.4.1/../../../../powerpc-unknown-linux-gnu/bin/as -mppc -many -V -Qy -maltivec -o arch/ppc/kernel/.tmp_time.o time.s
GNU assembler version 2.14 (powerpc-unknown-linux-gnu) using BFD version 2.14 20030612
time.s: Assembler messages:
time.s:145: Error: Unrecognized opcode: `mftb'
time.s:341: Error: Unrecognized opcode: `mftb'
time.s:462: Error: Unrecognized opcode: `mftb'
time.s:644: Error: Unrecognized opcode: `mftb'
time.s:755: Error: Unrecognized opcode: `mftb'
time.s:964: Error: Unrecognized opcode: `mftbu'
time.s:965: Error: Unrecognized opcode: `mftb'
time.s:966: Error: Unrecognized opcode: `mftbu'

-many resets some as flags.
changing this to -Wa,-mppc,-maltivec should help, no idea if it breaks
other combinations.

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Tue, Jul 13, 2004 at 03:49:45PM +0200, Olaf Hering wrote:

>  On Mon, Jul 12, Tom Rini wrote:
>
> > +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).

Was this the bigger patch I sent, which sets AFLAGS += $(aflags-y) or
something else?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Tue, Jul 13, Tom Rini wrote:

> On Tue, Jul 13, 2004 at 03:49:45PM +0200, Olaf Hering wrote:
>
> >  On Mon, Jul 12, Tom Rini wrote:
> >
> > > +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).

gcc passes it without asking.

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Tue, Jul 13, 2004 at 04:02:20PM +0200, Olaf Hering wrote:

>  On Tue, Jul 13, Tom Rini wrote:
>
> > On Tue, Jul 13, 2004 at 03:49:45PM +0200, Olaf Hering wrote:
> >
> > >  On Mon, Jul 12, Tom Rini wrote:
> > >
> > > > +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).
>
> 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.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Tue, Jul 13, Tom Rini wrote:

> 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.

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Tue, Jul 13, 2004 at 05:18:54PM +0200, Olaf Hering wrote:
>  On Tue, Jul 13, Tom Rini wrote:
>
> > 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?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Tue, Jul 13, Tom Rini wrote:

> On Tue, Jul 13, 2004 at 05:18:54PM +0200, Olaf Hering wrote:
> >  On Tue, Jul 13, Tom Rini wrote:
> >
> > > 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?

 /home/olaf/toolchain/inst/binutils-2.14-gcc-3.4.1/lib/gcc/powerpc-unknown-linux-gnu/3.4.1/../../../../powerpc-unknown-linux-gnu/bin/as -mppc -many -V -Qy -maltivec -o arch/ppc/kernel/.tmp_time.o time.s
 /home/olaf/toolchain/inst/binutils-2.12.1-gcc-3.4.1/lib/gcc/powerpc-unknown-linux-gnu/3.4.1/../../../../powerpc-unknown-linux-gnu/bin/as -mppc -many -V -Qy -maltivec -o arch/ppc/kernel/.tmp_time.o time.s
 /home/olaf/toolchain/inst/binutils-2.15-gcc-3.4.1/lib/gcc/powerpc-unknown-linux-gnu/3.4.1/../../../../powerpc-unknown-linux-gnu/bin/as -mppc -many -V -Qy -maltivec -o arch/ppc/kernel/.tmp_time.o time.s

looks like gas 2.14 has different -many behaviour.


--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Tue, Jul 13, 2004 at 05:29:50PM +0200, Olaf Hering wrote:

>  On Tue, Jul 13, Tom Rini wrote:
>
> > On Tue, Jul 13, 2004 at 05:18:54PM +0200, Olaf Hering wrote:
> > >  On Tue, Jul 13, Tom Rini wrote:
> > >
> > > > 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?
[snip]
> looks like gas 2.14 has different -many behaviour.

Yes, gas 2.14 has a broken -many behavior, as I've described before.
But if only gcc-3.4 always passes -many, how common (i.e. is anyone
shipping) gcc-3.4 + binutils-2.14 ?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
** This list is shutting down 7/24/2004.

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Tue, Jul 13, 2004 at 05:29:50PM +0200, Olaf Hering wrote:

>  On Tue, Jul 13, Tom Rini wrote:
>
> > On Tue, Jul 13, 2004 at 05:18:54PM +0200, Olaf Hering wrote:
> > >  On Tue, Jul 13, Tom Rini wrote:
> > >
> > > > 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?

OK.  The following hasn't been tested on all binutils/gcc combinations
yet, but should, in the case of binutils-2.14 and gcc-3.4 tell the user
there will be a problem and stop.  Olaf, can you run this past your
matrix of toolchains?  Thanks.

Signed-off-by: Tom Rini <trini@kernel.crashing.org>

--- 1.55/arch/ppc/Makefile	2004-07-05 03:27:10 -07:00
+++ edited/arch/ppc/Makefile	2004-07-14 16:22:58 -07:00
@@ -22,7 +22,7 @@

 LDFLAGS_vmlinux	:= -Ttext $(KERNELLOAD) -Bstatic
 CPPFLAGS	+= -Iarch/$(ARCH)
-AFLAGS		+= -Iarch/$(ARCH)
+aflags-y	+= -Iarch/$(ARCH)
 cflags-y	+= -Iarch/$(ARCH) -msoft-float -pipe \
 		-ffixed-r2 -Wno-uninitialized -mmultiple
 CPP		= $(CC) -E $(CFLAGS)
@@ -31,10 +31,16 @@
 cflags-y	+= -mstring
 endif

+aflags-$(CONFIG_4xx)		+= -m405
 cflags-$(CONFIG_4xx)		+= -Wa,-m405
+aflags-$(CONFIG_6xx)		+= -maltivec
+cflags-$(CONFIG_6xx)		+= -Wa,-maltivec
+aflags-$(CONFIG_E500)		+= -me500
 cflags-$(CONFIG_E500)		+= -Wa,-me500
+aflags-$(CONFIG_PPC64BRIDGE)	+= -mppc64bridge
 cflags-$(CONFIG_PPC64BRIDGE)	+= -Wa,-mppc64bridge

+AFLAGS += $(aflags-y)
 CFLAGS += $(cflags-y)

 head-y				:= arch/ppc/kernel/head.o
@@ -106,17 +112,23 @@
 else
 NEW_AS	:= 0
 endif
+# gcc-3.4 and binutils-2.14 are a fatal combination.
+GCC_VERSION	:= $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
+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)
+	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no lonber build '
+	@echo 'correctly with gcc-3.4 and your version of binutils.'
+	@echo '*** Please upgrade your binutils or downgrade your gcc'
+endif
+ifneq ($(NEW_AS),0)
 	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build '
 	@echo 'correctly with old versions of binutils.'
 	@echo '*** Please upgrade your binutils to ${GOODVER} or newer'
 	@false
-else
-checkbin:
-	@true
 endif
+	@true

 CLEAN_FILES +=	include/asm-$(ARCH)/offsets.h \
 		arch/$(ARCH)/kernel/asm-offsets.s
--- 1.47/arch/ppc/kernel/Makefile	2004-06-17 23:41:08 -07:00
+++ edited/arch/ppc/kernel/Makefile	2004-07-12 08:22:12 -07:00
@@ -2,16 +2,6 @@
 # Makefile for the linux kernel.
 #

-ifdef CONFIG_PPC64BRIDGE
-EXTRA_AFLAGS		:= -Wa,-mppc64bridge
-endif
-ifdef CONFIG_4xx
-EXTRA_AFLAGS		:= -Wa,-m405
-endif
-ifdef CONFIG_E500
-EXTRA_AFLAGS		:= -Wa,-me500
-endif
-
 extra-$(CONFIG_PPC_STD_MMU)	:= head.o
 extra-$(CONFIG_40x)		:= head_4xx.o
 extra-$(CONFIG_44x)		:= head_44x.o
@@ -35,7 +25,5 @@
 obj-$(CONFIG_TAU)		+= temp.o
 obj-$(CONFIG_ALTIVEC)		+= vecemu.o vector.o

-ifdef CONFIG_MATH_EMULATION
-obj-$(CONFIG_8xx)		+= softemu8xx.o
-endif
-
+sw-math-emu-$(CONFIG_8xx)	+= softemu8xx.o
+obj-$(CONFIG_MATH_EMULATION)	+= $(sw-math-emu-y)
--- 1.17/arch/ppc/mm/Makefile	2004-06-17 23:41:08 -07:00
+++ edited/arch/ppc/mm/Makefile	2004-07-12 08:22:21 -07:00
@@ -2,10 +2,6 @@
 # Makefile for the linux ppc-specific parts of the memory manager.
 #

-ifdef CONFIG_PPC64BRIDGE
-EXTRA_AFLAGS		:= -Wa,-mppc64bridge
-endif
-
 obj-y				:= fault.o init.o mem_pieces.o \
 					mmu_context.o pgtable.o

--- 1.31/arch/ppc/platforms/Makefile	2004-06-16 11:22:35 -07:00
+++ edited/arch/ppc/platforms/Makefile	2004-07-12 08:22:27 -07:00
@@ -2,29 +2,23 @@
 # Makefile for the linux kernel.
 #

-ifdef CONFIG_PPC64BRIDGE
-EXTRA_AFLAGS		:= -Wa,-mppc64bridge
-endif
-ifdef CONFIG_40x
-EXTRA_AFLAGS		:= -Wa,-m405
-endif
-
 # Extra CFLAGS so we don't have to do relative includes
 CFLAGS_pmac_setup.o	+= -Iarch/$(ARCH)/mm

-obj-$(CONFIG_APUS)		+= apus_setup.o
-ifeq ($(CONFIG_APUS),y)
-obj-$(CONFIG_PCI)		+= apus_pci.o
-endif
+# Multiple dependancies
+apus-$(CONFIG_PCI)		+= apus_pci.o
+chrp-$(CONFIG_SMP)		+= chrp_smp.o
+pmac-$(CONFIG_NVRAM)		+= pmac_nvram.o
+pmac-$(CONFIG_CPU_FREQ_PMAC)	+= pmac_cpufreq.o
+pmac-$(CONFIG_SMP)		+= pmac_smp.o
+
+obj-$(CONFIG_APUS)		+= apus_setup.o $(apus-y)
 obj-$(CONFIG_PPC_PMAC)		+= pmac_pic.o pmac_setup.o pmac_time.o \
 					pmac_feature.o pmac_pci.o pmac_sleep.o \
-					pmac_low_i2c.o
-obj-$(CONFIG_PPC_CHRP)		+= chrp_setup.o chrp_time.o chrp_pci.o
+					pmac_low_i2c.o $(pmac-y)
+obj-$(CONFIG_PPC_CHRP)		+= chrp_setup.o chrp_time.o chrp_pci.o \
+					$(chrp-y)
 obj-$(CONFIG_PPC_PREP)		+= prep_pci.o prep_setup.o
-ifeq ($(CONFIG_PPC_PMAC),y)
-obj-$(CONFIG_NVRAM)		+= pmac_nvram.o
-obj-$(CONFIG_CPU_FREQ_PMAC)	+= pmac_cpufreq.o
-endif
 obj-$(CONFIG_PMAC_BACKLIGHT)	+= pmac_backlight.o
 obj-$(CONFIG_PPC_RTAS)		+= error_log.o proc_rtas.o
 obj-$(CONFIG_PREP_RESIDUAL)	+= residual.o
@@ -48,8 +42,3 @@
 obj-$(CONFIG_SANDPOINT)		+= sandpoint.o
 obj-$(CONFIG_SBC82xx)		+= sbc82xx.o
 obj-$(CONFIG_SPRUCE)		+= spruce.o
-
-ifeq ($(CONFIG_SMP),y)
-obj-$(CONFIG_PPC_PMAC)		+= pmac_smp.o
-obj-$(CONFIG_PPC_CHRP)		+= chrp_smp.o
-endif
--- 1.3/arch/ppc/platforms/tqm8260_setup.c	2004-06-16 10:56:13 -07:00
+++ edited/arch/ppc/platforms/tqm8260_setup.c	2004-07-12 08:17:30 -07:00
@@ -77,3 +77,4 @@

 	callback_setup_arch	= ppc_md.setup_arch;
 	ppc_md.setup_arch	= tqm8260_setup_arch;
+}
--- 1.29/arch/ppc/syslib/Makefile	2004-07-01 22:23:46 -07:00
+++ edited/arch/ppc/syslib/Makefile	2004-07-12 08:22:30 -07:00
@@ -2,39 +2,27 @@
 # Makefile for the linux kernel.
 #

-ifdef CONFIG_PPC64BRIDGE
-EXTRA_AFLAGS		:= -Wa,-mppc64bridge
-endif
-ifdef CONFIG_4xx
-EXTRA_AFLAGS		:= -Wa,-m405
-endif
-ifdef CONFIG_E500
-EXTRA_AFLAGS		:= -Wa,-me500
-endif
-
 CFLAGS_prom_init.o      += -fPIC
 CFLAGS_btext.o          += -fPIC

+# Multiple dependancies
+ibm-4xx-$(CONFIG_GEN_RTC)	+= todc_time.o
+ibm-4xx-$(CONFIG_KGDB)		+= ppc4xx_kgdb.o
+ibm-40x-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o ppc405_pci.o
+mpc-8xx-$(CONFIG_PCI)		+= qspan_pci.o i8259.o
+gen550-$(CONFIG_KGDB)		+= gen550_kgdb.o gen550_dbg.o
+gen550-$(CONFIG_SERIAL_TEXT_DEBUG)	+= gen550_dbg.o
+mpc-85xx-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o
+
 obj-$(CONFIG_PPCBUG_NVRAM)	+= prep_nvram.o
 obj-$(CONFIG_PPC_OCP)		+= ocp.o
 obj-$(CONFIG_IBM_OCP)		+= ibm_ocp.o
 obj-$(CONFIG_44x)		+= ibm44x_common.o
 obj-$(CONFIG_440GP)		+= ibm440gp_common.o
 obj-$(CONFIG_440GX)		+= ibm440gx_common.o
-ifeq ($(CONFIG_4xx),y)
-obj-$(CONFIG_4xx)		+= ppc4xx_pic.o
-obj-$(CONFIG_40x)		+= ppc4xx_setup.o
-obj-$(CONFIG_GEN_RTC)		+= todc_time.o
-obj-$(CONFIG_KGDB)		+= ppc4xx_kgdb.o
-ifeq ($(CONFIG_40x),y)
-obj-$(CONFIG_KGDB)		+= ppc4xx_kgdb.o
-obj-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o ppc405_pci.o
-endif
-endif
-obj-$(CONFIG_8xx)		+= m8xx_setup.o ppc8xx_pic.o
-ifeq ($(CONFIG_8xx),y)
-obj-$(CONFIG_PCI)		+= qspan_pci.o i8259.o
-endif
+obj-$(CONFIG_4xx)		+= ppc4xx_pic.o $(ibm-4xx-y)
+obj-$(CONFIG_40x)		+= ppc4xx_setup.o $(ibm-40x-y)
+obj-$(CONFIG_8xx)		+= m8xx_setup.o ppc8xx_pic.o $(mpc-8xx-y)
 obj-$(CONFIG_PPC_OF)		+= prom_init.o prom.o of_device.o
 obj-$(CONFIG_PPC_PMAC)		+= open_pic.o indirect_pci.o
 obj-$(CONFIG_POWER4)		+= open_pic2.o
@@ -73,16 +61,11 @@
 obj-$(CONFIG_PCI_8260)		+= m8260_pci.o indirect_pci.o
 obj-$(CONFIG_8260_PCI9)		+= m8260_pci_erratum9.o
 obj-$(CONFIG_CPM2)		+= cpm2_common.o
-ifeq ($(CONFIG_PPC_GEN550),y)
-obj-$(CONFIG_KGDB)		+= gen550_kgdb.o gen550_dbg.o
-obj-$(CONFIG_SERIAL_TEXT_DEBUG)	+= gen550_dbg.o
-endif
+obj-$(CONFIG_PPC_GEN550)	+= $(gen550-y)
 obj-$(CONFIG_BOOTX_TEXT)	+= btext.o
 obj-$(CONFIG_MPC10X_BRIDGE)     += mpc10x_common.o indirect_pci.o
 obj-$(CONFIG_MPC10X_OPENPIC)	+= open_pic.o
 obj-$(CONFIG_40x)		+= dcr.o
 obj-$(CONFIG_BOOKE)		+= dcr.o
-obj-$(CONFIG_85xx)		+= open_pic.o ppc85xx_common.o ppc85xx_setup.o
-ifeq ($(CONFIG_85xx),y)
-obj-$(CONFIG_PCI)		+= indirect_pci.o pci_auto.o
-endif
+obj-$(CONFIG_85xx)		+= open_pic.o ppc85xx_common.o ppc85xx_setup.o \
+					$(mpc-85xx-y)

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Geert Uytterhoeven]

On Wed, 14 Jul 2004, Tom Rini wrote:
> +	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no lonber build '
                                                          ^^^^^^
							  longer

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Wed, Jul 14, Tom Rini wrote:


> +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.

--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Thu, Jul 15, 2004 at 02:50:32PM +0200, Olaf Hering wrote:

>  On Wed, Jul 14, Tom Rini wrote:
>
>
> > +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'.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Thu, Jul 15, 2004 at 02:50:32PM +0200, Olaf Hering wrote:

>  On Wed, Jul 14, Tom Rini wrote:
>
>
> > +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.

There was a slight problem with the first patch.  The following on top
of it should fix things (lightly tested by making sure I could make it
fail):
diff -u edited/arch/ppc/Makefile edited/arch/ppc/Makefile
--- edited/arch/ppc/Makefile	2004-07-14 16:22:58 -07:00
+++ edited/arch/ppc/Makefile	2004-07-15 07:20:40 -07:00
@@ -114,13 +114,14 @@
 endif
 # gcc-3.4 and binutils-2.14 are a fatal combination.
 GCC_VERSION	:= $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
-BAD_GCC_AS	:= $(shell echo mftb 5 | $(AS) -mppc -many -o /dev/null 2>/dev/null 2>&1 && echo 0 || echo 1)
+BAD_GCC_AS	:= $(shell echo mftb 5 | $(AS) -mppc -many -o /dev/null >/dev/null 2>&1 && echo 0 || echo 1)

 checkbin:
 ifeq ($(GCC_VERSION)$(BAD_GCC_AS),03041)
-	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no lonber build '
+	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build '
 	@echo 'correctly with gcc-3.4 and your version of binutils.'
 	@echo '*** Please upgrade your binutils or downgrade your gcc'
+	@false
 endif
 ifneq ($(NEW_AS),0)
 	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build '

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Olaf Hering]

 On Thu, Jul 15, Tom Rini wrote:

> On Thu, Jul 15, 2004 at 02:50:32PM +0200, Olaf Hering wrote:
>
> >  On Wed, Jul 14, Tom Rini wrote:
> >
> >
> > > +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'.

It should be '-o /dev/null >/dev/null 2>&1 ; echo $$?'
A @false is also missing.


diff -purN linux-2.6.8-rc1.trini/arch/ppc/Makefile linux-2.6.8-rc1/arch/ppc/Makefile
--- linux-2.6.8-rc1.trini/arch/ppc/Makefile	2004-07-15 16:22:12.355246237 +0200
+++ linux-2.6.8-rc1/arch/ppc/Makefile	2004-07-15 16:23:18.693626129 +0200
@@ -114,13 +114,14 @@ NEW_AS	:= 0
 endif
 # gcc-3.4 and binutils-2.14 are a fatal combination.
 GCC_VERSION	:= $(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-version.sh $(CC))
-BAD_GCC_AS	:= $(shell echo mftb 5 | $(AS) -mppc -many -o /dev/null 2>/dev/null 2>&1 && echo 0 || echo 1)
+BAD_GCC_AS	:= $(shell echo mftb 5 | $(AS) -mppc -many -o /dev/null >/dev/null 2>&1 ; echo $$?)

 checkbin:
 ifeq ($(GCC_VERSION)$(BAD_GCC_AS),03041)
-	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no lonber build '
+	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build '
 	@echo 'correctly with gcc-3.4 and your version of binutils.'
 	@echo '*** Please upgrade your binutils or downgrade your gcc'
+	@false
 endif
 ifneq ($(NEW_AS),0)
 	@echo -n '*** ${VERSION}.${PATCHLEVEL} kernels no longer build '
--
USB is for mice, FireWire is for men!

sUse lINUX ag, nÜRNBERG

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Alan Modra]

On Sun, Jul 04, 2004 at 11:33:31AM -0500, Hollis Blanchard wrote:
> On Jul 4, 2004, at 3:32 AM, Geert Uytterhoeven wrote:
> >
> >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.
>
> 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.  :-)

@item .machine "string"
This directive allows you to change the machine for which code is
generated.  @code{"string"} may be any of the -m cpu selection options
(without the -m) enclosed in double quotes, @code{"push"}, or
@code{"pop"}.  @code{.machine "push"} saves the currently selected
cpu, which may be restored with @code{.machine "pop"}.

--
Alan Modra
IBM OzLabs - Linux Technology Centre

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Sun, Jul 25, 2004 at 03:37:54PM +0930, Alan Modra wrote:

> On Sun, Jul 04, 2004 at 11:33:31AM -0500, Hollis Blanchard wrote:
> > On Jul 4, 2004, at 3:32 AM, Geert Uytterhoeven wrote:
> > >
> > >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.
> >
> > 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 ?

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Alan Modra]

On Mon, Jul 26, 2004 at 12:36:52PM -0700, Tom Rini wrote:
[about ppc .machine]
> But working in what versions of binutils ?

HJ's 2.14.90.0.8 and later, FSF 2.15 release.

--
Alan Modra
IBM OzLabs - Linux Technology Centre

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: [PATCH] fix missing option in binutils version check

[Tom Rini]

On Tue, Jul 27, 2004 at 08:33:53AM +0930, Alan Modra wrote:

> On Mon, Jul 26, 2004 at 12:36:52PM -0700, Tom Rini wrote:
> [about ppc .machine]
> > But working in what versions of binutils ?
>
> HJ's 2.14.90.0.8 and later, FSF 2.15 release.

OK.  I suppose when we force 2.15 as a miniumum we need to remember to
revist using this then.  Thanks.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/