On 5/24/07, Elford, Chris L <[EMAIL PROTECTED]> wrote:
Hi all, I tracked down a system that has SSE but not SSE2 (a dual processor P3 system). For me, adding "-xe ii" to the ntsd command line let the debugger break in at the first chance exception. It reports that what I believe is an SSE2 instruction does indeed happen during jitrino.dll startup. 01365fb0 f20f100520553901 movsd xmm0,qword ptr [jitrino!JIT_gc_start+0xd5810 (01395520)] Without jitrino symbol information (e.g., a pdb file for jitrino.dll), its hard to tell what function is being executed (it is unlikely that it is JIT_gc_start. It would be nice if the snapshot builds included symbol files to help make for more meaningful stack traces. It may be good to discuss [again?] on the lists whether more people can come into the project to help create legacy modes that earlier instruction sets (and earlier Oses) can still execute without crippling current instruction set processors (and/or OSes). I don't see an open JIRA about this one. The closest I see is http://issues.apache.org/jira/browse/HARMONY-3246 which is more about code that the JIT creates rather than the JIT itself. Ntsd log below showing more detail around faulting instruction. Mikhail?
You're right that we fixed Jitrino.OPT to generate SSE independent code (use x87) if SSE2 is not available. Another JIRA (not commited yet): http://issues.apache.org/jira/browse/HARMONY-3737 makes JET to compile all methods without FPU insts (>90% of methods) and pass other methods to OPT I checked dumpbin /disasm for jitrino.dll and see a lot of SSE/SSE2 insts in code. It's possible that our compiler options for jitrino.dll are too aggressive. I will check it and report. -- Mikhail Fursov
