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