Michal Necasek
2006-02-14 03:07:16 UTC
Maybe people still remember the discussion about the floating-point
control word getting corrupted in certain situations. I have since made
some discoveries, but the diagnosis is extremely difficult because:
- If I run the testcase - a VIO app running in a PM window - under a
debugger (IBM, Watcom, or just homebrew DosDebug thingy), the behaviour
is altered and the bug does not occur; the initialization sequence of
the process is different and some DLLs get loaded earlier.
- When the corruption occurs, it is after a call to DosWrite to the
console. This will load the BVH subsystem *unless* output is redirected.
There may be other calls that will cause DLLs to load and corrupt the FPCW.
- I have not managed to track this down through KDB because it appears
to offer absolutely no way of displaying any floating-point registers.
- I did discover that my own SDDPMI.DLL is involved; however, SDDPMI
itself doesn't even use floating-point and the culprit is either the
VAC++ runtime or possibly SOM.DLL.
- When I prevented SDDPMI from messing with the FPCW, it was no longer
getting trashed in FS sessions, but was still modified in VIO windows.
In fact the FPCW was getting corrupted even when plain VGAGRADD was
used. Since most if not all of the DLLs in question are using IBM's
runtime, this is probably not surprising. Unfortunately, a VIO app will
load quite a few PM DLLs the first time it does console I/O.
Right now I can't tell which other DLL is responsible (could be more
than one) - I haven't found a tool that is not a Ring 3 debugger, will
let me stop at each DLL load, *and* will display the FPCW.
Michal
control word getting corrupted in certain situations. I have since made
some discoveries, but the diagnosis is extremely difficult because:
- If I run the testcase - a VIO app running in a PM window - under a
debugger (IBM, Watcom, or just homebrew DosDebug thingy), the behaviour
is altered and the bug does not occur; the initialization sequence of
the process is different and some DLLs get loaded earlier.
- When the corruption occurs, it is after a call to DosWrite to the
console. This will load the BVH subsystem *unless* output is redirected.
There may be other calls that will cause DLLs to load and corrupt the FPCW.
- I have not managed to track this down through KDB because it appears
to offer absolutely no way of displaying any floating-point registers.
- I did discover that my own SDDPMI.DLL is involved; however, SDDPMI
itself doesn't even use floating-point and the culprit is either the
VAC++ runtime or possibly SOM.DLL.
- When I prevented SDDPMI from messing with the FPCW, it was no longer
getting trashed in FS sessions, but was still modified in VIO windows.
In fact the FPCW was getting corrupted even when plain VGAGRADD was
used. Since most if not all of the DLLs in question are using IBM's
runtime, this is probably not surprising. Unfortunately, a VIO app will
load quite a few PM DLLs the first time it does console I/O.
Right now I can't tell which other DLL is responsible (could be more
than one) - I haven't found a tool that is not a Ring 3 debugger, will
let me stop at each DLL load, *and* will display the FPCW.
Michal