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