User account creation filtered due to spam.

Bug 15905 - frstor in assembler inline offsets in memory by 4
Summary: frstor in assembler inline offsets in memory by 4
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.3.2
: P2 critical
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-09 20:38 UTC by stian
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host: x86-linux-gnu
Target: x86-linux-gnu
Build: x86-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description stian 2004-06-09 20:38:55 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):


#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;
}
Comment 1 Andrew Pinski 2004-06-09 20:41:13 UTC
Are you saying when you run this program locks up your computer if so this is not a gcc bug.
Comment 2 stian 2004-06-09 20:47:43 UTC
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).
Comment 3 Andrew Pinski 2004-06-09 21:04:12 UTC
Not a gcc bug.
Comment 4 stian 2004-06-11 19:21:18 UTC
*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)
Comment 5 Andrew Pinski 2004-06-11 19:24:33 UTC
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.
Comment 6 stian 2004-06-12 01:08:17 UTC
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.