lkml.org 
[lkml]   [2008]   [May]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] x86: xsave/xrstor support, ucontext_t extensions
H. Peter Anvin writes:
> Michael, you wrote:
>
> > Hmm, right now it seems this field has a de-facto ABI of being
> > either 0xffff (plain) or 0x0000 (fxsr). Using other values would
> > confuse at least one application I know of. Sad.
>
> ... could you share what application that is? This otherwise would be
> ideal.

It's the virtual machine for the Erlang/OTP concurrent functional
language. It's open-source and used extensively for telecom and
internet server applications.

The language doesn't allow non-finite FP values, so FP ops must
be checked. As an optimisation, the virtual machine groups FP ops
into blocks, enables FP exceptions, and has a SIGFPE handler that
just records that an FP exception has occurred in a per-thread flag.
After each FP block there's a single check for this flag, which if
set triggers a language-level "badarith" exception.

In order to resume from an SSE2 exception the SIGFPE handler must
update some parts of the sigcontext. But first the handler must detect
if the exception came from x87 or SSE2, which requires looking at the
mxcsr field, which requires looking at the magic field to detect the
fpstate's layout.

The magic field is described as follows in sigcontext.h:

>struct _fpstate {
> ...
> unsigned short magic; /* 0xffff = regular FPU data only */
> ...
>};
>
>#define X86_FXSR_MAGIC 0x0000

While this in theory allows for other values than -1 and 0 in magic,
any such value would be != FXSR_MAGIC and therefore would not trigger
the application's "inspect the fxsr layout" logic.

/Mikael


\
 
 \ /
  Last update: 2008-05-23 13:53    [W:0.220 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site