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): #include <sys/time.h> #include <signal.h> #include <unistd.h> static void Handler(int ignore) { char fpubuf[108]; __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; signal(SIGALRM, Handler); spec.it_interval.tv_sec=0; spec.it_interval.tv_usec=100; spec.it_value.tv_sec=0; spec.it_value.tv_usec=100; setitimer(ITIMER_REAL, &spec, NULL); while(1) write(1, ".", 1); return 0; }
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* Handler: pushl %ebp movl %esp, %ebp subl $136, %esp leal -120(%ebp), %eax movl %eax, -124(%ebp) #APP fsave -124(%ebp) #NO_APP subl $4, %esp pushl $1 pushl $.LC0 pushl $2 call write addl $16, %esp leal -120(%ebp), %eax movl %eax, -128(%ebp) #APP frstor -128(%ebp) #NO_APP leave ret 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.