GCC Bugzilla – Bug 15905
frstor in assembler inline offsets in memory by 4
Last modified: 2005-07-23 22:49:57 UTC
I'm on a vacation and doing some hobby project and came across a minor fault
when using assembler inlines. Result is the my linux console totally freezes
(Can't even CAD the console, but ALT SysRQ still works). This problem must be a
race since it doesn't trigger when system is loaded, or processes is straced.
I'm not able to update my versions for some weeks due to my vacation, so
problems might be fixes. I find this both to be a bug in gcc, that again
triggers a kernel bug.
I need confirmation if this is an issue with gcc here (looks like the frstor is
off by 4 compared to the address fsave gets).
GCC version 3.3 and 3.3.2
Kernel version 2.4.26-rc1 vanilla
And this is my .c file written down by hand (might contain typos):
static void Handler(int ignore)
__asm__ __volatile__ ("fsave %0\n" : : "m"(fpubuf));
write(2, "*", 1);
__asm__ __volatile__ ("frstor %0\n" : : "m"(fpubuf));
int main(int argc, char *argv)
struct itimerval spec;
setitimer(ITIMER_REAL, &spec, NULL);
write(1, ".", 1);
Are you saying when you run this program locks up your computer if so this is not a gcc bug.
It locks my computer yes, but when I compiled using -S flag and looked at the
assembler output, the fsave and frstore is not given the same offset in the
stackframe. fsave is -124(%ebp) while frstor is -128(%ebp).
Not a gcc bug.
*pasting disassembled result*
movl %esp, %ebp
subl $136, %esp
leal -120(%ebp), %eax
movl %eax, -124(%ebp)
subl $4, %esp
addl $16, %esp
leal -120(%ebp), %eax
movl %eax, -128(%ebp)
the frstor and fsave does not appear to feed with the same address if you ask
me. So you meen that the offsets to ebp should differ? (the kernel lock is just
a side effect of this I believe)
You most likely want:
__asm__ __volatile__ ("fsave %0\n" : : "m"(*fpubuf));
and not what you have.
Likewise for the frstor, other wise you are passing the address of fpubuf.
Thanks for the respons. Seems to be harder to get up the eyes of the kernel
people, since the floating point exceptions inside that signal handler fucks up
the current linux-kernels. Haven't got any respons from any of the kernel
developers yet. A bit scary I think. But a big thanks to you atleast for given
this some attention.