On Mon, Jan 9, 2012 at 11:40, Andreas Schwab <schwab@xxxxxxxxxxxxxx> wrote:
Alan Hourihane <alanh@xxxxxxxxxxxxxx> writes:
*** FORMAT ERROR *** FORMAT=0
Current process id is 768
BAD KERNEL TRAP: 00000000
Modules linked in:
PC: [<000029de>] flush_thread+0x8/0xe
void flush_thread(void)
{
unsigned long zero = 0;
current->thread.fs = __USER_DS;
if (!FPU_IS_EMU)
asm volatile (".chip 68k/68881\n\t"
"frestore %0@\n\t"
".chip 68k" : : "a" (&zero));
}
GCC is optimizing away the initialisation of zero, since nothing visible
is using its value.
Andreas.
--------------------------->8----------------------------------------
From bbf7451db90fcec5eade9d8bc913b78829192b9c Mon Sep 17 00:00:00 2001
From: Andreas Schwab <schwab@xxxxxxxxxxxxxx>
Date: Mon, 9 Jan 2012 11:36:18 +0100
Subject: [PATCH] m68k: fix assembler constraint to prevent overeager gcc
optimisation
Passing the address of a variable as an operand to an asm statement
doesn't mark the value of this variable as used, so gcc optimized its
initialisation away. Fix this by using a "m" constraint instead.
---
arch/m68k/kernel/process_mm.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/m68k/kernel/process_mm.c b/arch/m68k/kernel/process_mm.c
index 1bc223a..aa4ffb8 100644
--- a/arch/m68k/kernel/process_mm.c
+++ b/arch/m68k/kernel/process_mm.c
@@ -189,8 +189,8 @@ void flush_thread(void)
current->thread.fs = __USER_DS;
if (!FPU_IS_EMU)
asm volatile (".chip 68k/68881\n\t"
- "frestore %0@\n\t"
- ".chip 68k" : : "a" (&zero));
+ "frestore %0\n\t"
+ ".chip 68k" : : "m" (zero));
}
/*
--
1.7.8.3
Thanks!
Tuomas: I think this will fix your problem, too?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
