From: Olaf Hering <hidden> Date: 2004-06-05 07:43:41
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.
@@ -94,7 +94,7 @@ endififneq ($(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/
From: Christian Kujau <hidden> Date: 2004-06-05 10:40:52
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/
From: Olaf Hering <hidden> Date: 2004-06-05 11:11:35
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/
From: Christian Kujau <hidden> Date: 2004-06-05 13:11:22
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/
On Sat, Jun 05, 2004 at 01:11:35PM +0200, Olaf Hering wrote:
On Sat, Jun 05, Christian Kujau wrote:
quoted
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/
From: Olaf Hering <hidden> Date: 2004-06-08 11:25:56
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
@@ -86,7 +86,7 @@ include/asm-$(ARCH)/offsets.h: arch/$(ARifdef CONFIG_6xx# Ensure this is binutils 2.12.1 (or 2.12.90.0.7) or later-NEW_AS:=$(shellechodssall|$(AS)-o/dev/null>/dev/null2>&1;echo$$?)+NEW_AS:=$(shellechodssall|$(AS)-many-o/dev/null>/dev/null2>&1;echo$$?)GOODVER:=2.12.1elseNEW_AS:=0
@@ -94,7 +94,7 @@ endififneq ($(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/
On Tue, Jun 08, 2004 at 01:25:56PM +0200, Olaf Hering wrote:
On Sat, Jun 05, Olaf Hering wrote:
quoted
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/
From: Olaf Hering <hidden> Date: 2004-06-14 09:15:30
On Wed, Jun 09, Tom Rini wrote:
On Tue, Jun 08, 2004 at 01:25:56PM +0200, Olaf Hering wrote:
quoted
On Sat, Jun 05, Olaf Hering wrote:
quoted
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/
On Mon, Jun 14, 2004 at 11:15:30AM +0200, Olaf Hering wrote:
On Wed, Jun 09, Tom Rini wrote:
quoted
On Tue, Jun 08, 2004 at 01:25:56PM +0200, Olaf Hering wrote:
quoted
On Sat, Jun 05, Olaf Hering wrote:
quoted
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/
From: Olaf Hering <hidden> Date: 2004-06-14 17:38:41
On Mon, Jun 14, Tom Rini wrote:
quoted
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/
From: Olaf Hering <hidden> Date: 2004-06-14 18:07:34
On Mon, Jun 14, Olaf Hering wrote:
On Mon, Jun 14, Tom Rini wrote:
quoted
quoted
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
On Mon, Jun 14, 2004 at 08:07:34PM +0200, Olaf Hering wrote:
quoted hunk
On Mon, Jun 14, Olaf Hering wrote:
quoted
On Mon, Jun 14, Tom Rini wrote:
quoted
quoted
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
... 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/
From: Olaf Hering <hidden> Date: 2004-06-14 21:19:31
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 [off-list ref]
* 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/
On Mon, Jun 14, 2004 at 11:19:31PM +0200, Olaf Hering wrote:
On Mon, Jun 14, Tom Rini wrote:
quoted
... 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
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/
From: Olaf Hering <hidden> Date: 2004-06-15 17:25:11
On Tue, Jun 15, Tom Rini wrote:
On Mon, Jun 14, 2004 at 11:19:31PM +0200, Olaf Hering wrote:
quoted
On Mon, Jun 14, Tom Rini wrote:
quoted
... 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?
quoted
quoted
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/
On Tue, Jun 15, 2004 at 07:25:11PM +0200, Olaf Hering wrote:
On Tue, Jun 15, Tom Rini wrote:
quoted
On Mon, Jun 14, 2004 at 11:19:31PM +0200, Olaf Hering wrote:
quoted
On Mon, Jun 14, Tom Rini wrote:
quoted
... 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 :)
quoted
quoted
quoted
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/
From: Olaf Hering <hidden> Date: 2004-07-03 22:29:18
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
@@ -24,6 +24,9 @@ ifndef CONFIG_E500cflags-y+=-mstringendif+# gcc 3.2.3 passes -mppc,+# the altivec asm code will fail to compile with binutils newer than 2.15+cflags-$(CONFIG_6xx)+=-Wa,-manycflags-$(CONFIG_4xx)+=-Wa,-m405cflags-$(CONFIG_E500)+=-Wa,-me500cflags-$(CONFIG_PPC64BRIDGE)+=-Wa,-mppc64bridge
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?
On Sun, Jul 04, 2004 at 03:30:47AM +0200, Stef Simoens wrote:
Olaf Hering wrote:
quoted
On Tue, Jun 15, Tom Rini wrote:
quoted
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.
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/
From: Olaf Hering <hidden> Date: 2004-07-04 07:23:50
On Sun, Jul 04, Olaf Hering wrote:
On Tue, Jun 15, Tom Rini wrote:
quoted
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
@@ -24,6 +24,9 @@ ifndef CONFIG_E500cflags-y+=-mstringendif+# gcc 3.2.3 passes -mppc,+# the altivec asm code will fail to compile with binutils newer than 2.15+cflags-$(CONFIG_6xx)+=-Wa,-manycflags-$(CONFIG_4xx)+=-Wa,-m405cflags-$(CONFIG_E500)+=-Wa,-me500cflags-$(CONFIG_PPC64BRIDGE)+=-Wa,-mppc64bridge
On Sun, Jul 04, 2004 at 03:30:47AM +0200, Stef Simoens wrote:
quoted
Olaf Hering wrote:
quoted
On Tue, Jun 15, Tom Rini wrote:
quoted
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/
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/
On Sun, Jul 04, 2004 at 10:32:52AM +0200, Geert Uytterhoeven wrote:
On Sat, 3 Jul 2004, Tom Rini wrote:
quoted
On Sun, Jul 04, 2004 at 03:30:47AM +0200, Stef Simoens wrote:
quoted
Olaf Hering wrote:
quoted
On Tue, Jun 15, Tom Rini wrote:
quoted
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/
On Sun, Jul 04, 2004 at 12:29:18AM +0200, Olaf Hering wrote:
On Tue, Jun 15, Tom Rini wrote:
quoted
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.
@@ -24,6 +24,9 @@ ifndef CONFIG_E500cflags-y+=-mstringendif+# 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.
On Sun, Jul 04, 2004 at 09:23:50AM +0200, Olaf Hering wrote:
On Sun, Jul 04, Olaf Hering wrote:
quoted
On Tue, Jun 15, Tom Rini wrote:
quoted
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 <redacted>
===== arch/ppc/Makefile 1.54 vs edited =====
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/
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:
quoted
On Sun, Jul 04, Olaf Hering wrote:
quoted
On Tue, Jun 15, Tom Rini wrote:
quoted
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 <redacted>
===== arch/ppc/Makefile 1.78 vs edited =====
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/
From: Olaf Hering <hidden> Date: 2004-07-12 09:06:18
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
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.
On Mon, Jul 12, 2004 at 11:06:18AM +0200, Olaf Hering wrote:
On Thu, Jul 08, Tom Rini wrote:
quoted
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 <redacted>
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:
quoted
On Thu, Jul 08, Tom Rini wrote:
quoted
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 <redacted>
@@ -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.oextra-$(CONFIG_40x):=head_4xx.oextra-$(CONFIG_44x):=head_44x.o
@@ -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.oinit.omem_pieces.o\mmu_context.opgtable.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 includesCFLAGS_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.opmac_setup.opmac_time.o\pmac_feature.opmac_pci.opmac_sleep.o\-pmac_low_i2c.o-obj-$(CONFIG_PPC_CHRP)+=chrp_setup.ochrp_time.ochrp_pci.o+pmac_low_i2c.o$(pmac-y)+obj-$(CONFIG_PPC_CHRP)+=chrp_setup.ochrp_time.ochrp_pci.o\+$(chrp-y)obj-$(CONFIG_PPC_PREP)+=prep_pci.oprep_setup.o-ifeq ($(CONFIG_PPC_PMAC),y)-obj-$(CONFIG_NVRAM)+=pmac_nvram.o-obj-$(CONFIG_CPU_FREQ_PMAC)+=pmac_cpufreq.o-endifobj-$(CONFIG_PMAC_BACKLIGHT)+=pmac_backlight.oobj-$(CONFIG_PPC_RTAS)+=error_log.oproc_rtas.oobj-$(CONFIG_PREP_RESIDUAL)+=residual.o
From: Olaf Hering <hidden> Date: 2004-07-13 13:49:45
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.
On Tue, Jul 13, 2004 at 03:49:45PM +0200, Olaf Hering wrote:
On Mon, Jul 12, Tom Rini wrote:
quoted
+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.
From: Olaf Hering <hidden> Date: 2004-07-13 14:02:20
On Tue, Jul 13, Tom Rini wrote:
On Tue, Jul 13, 2004 at 03:49:45PM +0200, Olaf Hering wrote:
quoted
On Mon, Jul 12, Tom Rini wrote:
quoted
+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.
On Tue, Jul 13, 2004 at 04:02:20PM +0200, Olaf Hering wrote:
On Tue, Jul 13, Tom Rini wrote:
quoted
On Tue, Jul 13, 2004 at 03:49:45PM +0200, Olaf Hering wrote:
quoted
On Mon, Jul 12, Tom Rini wrote:
quoted
+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.
From: Olaf Hering <hidden> Date: 2004-07-13 15:18:54
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.
On Tue, Jul 13, 2004 at 05:18:54PM +0200, Olaf Hering wrote:
On Tue, Jul 13, Tom Rini wrote:
quoted
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.
From: Olaf Hering <hidden> Date: 2004-07-13 15:29:50
On Tue, Jul 13, Tom Rini wrote:
On Tue, Jul 13, 2004 at 05:18:54PM +0200, Olaf Hering wrote:
quoted
On Tue, Jul 13, Tom Rini wrote:
quoted
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.
On Tue, Jul 13, 2004 at 05:29:50PM +0200, Olaf Hering wrote:
On Tue, Jul 13, Tom Rini wrote:
quoted
On Tue, Jul 13, 2004 at 05:18:54PM +0200, Olaf Hering wrote:
quoted
On Tue, Jul 13, Tom Rini wrote:
quoted
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.
On Tue, Jul 13, 2004 at 05:29:50PM +0200, Olaf Hering wrote:
On Tue, Jul 13, Tom Rini wrote:
quoted
On Tue, Jul 13, 2004 at 05:18:54PM +0200, Olaf Hering wrote:
quoted
On Tue, Jul 13, Tom Rini wrote:
quoted
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 <redacted>
@@ -106,17 +112,23 @@elseNEW_AS:=0endif+# 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:=$(shellechomftb5|$(AS)-mppc-many-o/dev/null2>/dev/null2>&1&&echo0||echo1)-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:-@trueendif+@trueCLEAN_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.oextra-$(CONFIG_40x):=head_4xx.oextra-$(CONFIG_44x):=head_44x.o
@@ -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.oinit.omem_pieces.o\mmu_context.opgtable.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 includesCFLAGS_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.opmac_setup.opmac_time.o\pmac_feature.opmac_pci.opmac_sleep.o\-pmac_low_i2c.o-obj-$(CONFIG_PPC_CHRP)+=chrp_setup.ochrp_time.ochrp_pci.o+pmac_low_i2c.o$(pmac-y)+obj-$(CONFIG_PPC_CHRP)+=chrp_setup.ochrp_time.ochrp_pci.o\+$(chrp-y)obj-$(CONFIG_PPC_PREP)+=prep_pci.oprep_setup.o-ifeq ($(CONFIG_PPC_PMAC),y)-obj-$(CONFIG_NVRAM)+=pmac_nvram.o-obj-$(CONFIG_CPU_FREQ_PMAC)+=pmac_cpufreq.o-endifobj-$(CONFIG_PMAC_BACKLIGHT)+=pmac_backlight.oobj-$(CONFIG_PPC_RTAS)+=error_log.oproc_rtas.oobj-$(CONFIG_PREP_RESIDUAL)+=residual.o
+ @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/
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/
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/
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
@@ -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:=$(shellechomftb5|$(AS)-mppc-many-o/dev/null2>/dev/null2>&1&&echo0||echo1)+BAD_GCC_AS:=$(shellechomftb5|$(AS)-mppc-many-o/dev/null>/dev/null2>&1&&echo0||echo1)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'+@falseendififneq ($(NEW_AS),0)@echo-n'*** ${VERSION}.${PATCHLEVEL} kernels no longer build '--
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
@@ -114,13 +114,14 @@ NEW_AS := 0endif# 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:=$(shellechomftb5|$(AS)-mppc-many-o/dev/null2>/dev/null2>&1&&echo0||echo1)+BAD_GCC_AS:=$(shellechomftb5|$(AS)-mppc-many-o/dev/null>/dev/null2>&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'+@falseendififneq ($(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/
From: Alan Modra <hidden> Date: 2004-07-25 06:07:54
On Sun, Jul 04, 2004 at 11:33:31AM -0500, Hollis Blanchard wrote:
On Jul 4, 2004, at 3:32 AM, Geert Uytterhoeven wrote:
quoted
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/
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:
quoted
On Jul 4, 2004, at 3:32 AM, Geert Uytterhoeven wrote:
quoted
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. :-)
From: Alan Modra <hidden> Date: 2004-07-26 23:03:53
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/