privileged instruction in 32-bit code

Tyler Nielsen tyler.nielsen at corniceco.com
Fri Nov 11 10:18:18 CST 2005


Andreas Mohr wrote:

>Hi,
>
>On Fri, Nov 11, 2005 at 10:36:24AM +0100, Marcus Meissner wrote:
>  
>
>>>(gdb) disassemble bar
>>>Dump of assembler code for function bar:
>>>0x080495a0 <bar+0>:     movaps %xmm0,(%ecx)
>>>0x080495a3 <bar+3>:     shufps $0xa,%xmm3,%xmm2
>>>0x080495a7 <bar+7>:     add    $0x90,%eax
>>>0x080495ac <bar+12>:    decl   0x4c(%esp)
>>>0x080495b0 <bar+16>:    movaps %xmm1,0x10(%ecx)
>>>0x080495b4 <bar+20>:    shufps $0x9d,%xmm3,%xmm2
>>>0x080495b8 <bar+24>:    mov    %edi,0x88(%esp)
>>>0x080495bf <bar+31>:    mov    0x64(%esp),%edi
>>>0x080495c3 <bar+35>:    movaps %xmm2,0x20(%ecx)
>>>0x080495c7 <bar+39>:    jne    0x80491b6
>>>
>>>I'm now fairly sure it's failing on the first movaps command.  Unless 
>>>someone can direct me differently, I'm going to start looking at why 
>>>that command is showing up as 'privileged'.
>>>      
>>>
>>Does your machine support SSE2 instructions? I guess this is the problem.
>>    
>>
>
>Thinking that stuff a bit further: I'd guess that an app usually knows when
>to use SSE2 and when not to use it (since it'd most likely crash the same
>way on Windows if it was wrong!).
>IOW, do we have an issue with some SystemInfo API indicating that we *have*
>an SSE2 CPU here when we actually have not, and thus the program chooses to
>switch to the improper code path?
>
>Andreas
>
>  
>
 From /proc/cpuinfo I see sse and sse2 in the flags.  So I don't think 
that this is because my cpu doesn't support it.  I would like to be able 
to dissable sse support and see if this fixes the problem, but I can't 
see an easy way to do this.  I have found the file dlls/kernel/cpu.c, 
and it seems like that is what I need to deal with.

Tyler




More information about the wine-devel mailing list