| Summary: | frstor in assembler inline offsets in memory by 4 | ||
|---|---|---|---|
| Product: | gcc | Reporter: | stian |
| Component: | c | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | critical | CC: | gcc-bugs, solar |
| Priority: | P2 | ||
| Version: | 3.3.2 | ||
| Target Milestone: | --- | ||
| Host: | x86-linux-gnu | Target: | x86-linux-gnu |
| Build: | x86-linux-gnu | Known to work: | |
| Known to fail: | Last reconfirmed: | ||
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. |
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; }