"Rein Klazes" rklazes@xs4all.nl wrote:
Attached disassembly is almost the same as assember generated by gcc (not counting garbage instead of jump table and fildl (gcc) vs. filds (winedbg))
The 8 instructions or so that I quoted would have been enough. And those instructions seem to be assembled OK. Btw did you ever check the value that was loaded in the CW, so the 16 bit value in -2(%edx) ?
Do you mean something like that?
Unhandled exception: c000008f in 32-bit code (0x40858a6e). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x40858a6e (X11DRV_PEN_SelectObject+0x8e [pen.c:69]): fldcw 0xfffffffe(%edx) 69 } Wine-dbg>info regs info regs Register dump: CS:0023 SS:002b DS:002b ES:002b FS:027f GS:0000 EIP:40858a6e ESP:42005a64 EBP:42005aac EFLAGS:00010202( R- 00 I - - 1 ) EAX:00001640 EBX:4087d00c ECX:4038c7bc EDX:42005a8c ESI:4038c160 EDI:40807054 Wine-dbg>x ($edx-2) x ($edx-2) 70001240 Wine-dbg>
I'm sorry, but At&T syntax is not familiar for me. Floating point assembler instructions either.
Also I don't understand why winedbg prints dc->xformWorld2Vport.eM11 = 0.0, though is always 1.0 in the log trace (added to X11DRV_PEN_SelectObject right before the GDI_ROUND call). Something wrong, but I don't know how proceed further yet. Any thoughts?
I would trust the trace, more then the debugger. Things can be really tricky though with floating points. The only way to be 100% sure is to to show the actual bit pattern. All zero's is 0.0. Anything else is not, but a printf can still print 0.0.
Patch from Eric cured the wine debugger.