I have read of some crashes with gdb under go32v2. So looking throught dpmiexcp.pp file I found in the djgpp_exception_toggle procedure a potential problem. The line

if (_os_trueversion  $532) and get_pm_exception_handler(i,_except) then

checks for NT-system to fallback into real mode DPMI 0.9 because, as in the comment, NT-system seems to not set carryflag. I think otherwise this problem is already fixed in the r152 where flag is passed properly onto the stack via the standard call, but regardless of that NT-system is continuing by the chunk

(_os_trueversion $532) and

to skip DPMI 1.0 protected mode even now it could use it. Unlucky I have only a Win98 box so I cannot test if one removes the above chunk, it will bring to a better result.
There's another similar question in the dpmi_set_coprocessor_emulation function, does the cdecl call handle correct the flag? Regards, Marco.

I compiled FPC-GO32V2 on my system with the previous modification, actually I have a WinME box which surprisiling is considered to have a NT- core. In fact the activated protected mode handler requires a more strictly compliance among the calls on the stack, you need to add the cdecl statement to the functions mcount_tick, timer in the profile.pp file and to the function nofpsig in the emu387.pp file.
Otherwise call to the dpmi_set_coprocessor_emulation function is safe because the parameter is always explicitly passed.

On Tue, April 22, 2008 22:12, wrote:

Hi Marco,

I'm sorry, but I'm not clear about the conclusion of all of this. If you aim to have something changed in the GO32v2 code, I'd need a clear reproducible scenario of what doesn't work before the proposed change and gets fixed by the proposed change, or comprehensible clarification why the current code is wrong and your proposed version is not (taking into account that the person who wrote the code probably won't be able to comment on this, so your clarification must be comprehensible even to somebody who doesn't know the particular code at all).

Tomas

Tomas Hajny wrote

I'm sorry, but I'm not clear about the conclusion of all of this. If you aim to have something changed in the GO32v2 code, I'd need a clear reproducible scenario of what doesn't work before the proposed change and gets fixed by the proposed change,

It's not easy to search for a smoking gun exploit, either as I start from the source and as a bug that arises from a real mode exception instead of protected mode is dependant by the around conditions. However I tried an attempt to compile the symify.pp and the ide with the debug bind (which work massively with the signals), but both the cases fail the final link because of a lot of missing variable or function references in the gdblib (does you know what is the correct version? I downloaded the v6.1.1 from the fpc ftp site). Despite of this, I withdraw on focuses to the calculator of the ide (which uses the floating point unit exception) and in occurring the zero division error. Does anyone have experienced an hang or crash in such way on a NT-machine? To me it behaves good.

Then I respawn from principle. In the dpmiexcp.pp file the djgpp_exception_toggle procedure sets the handler for a range of execptions. At a first glance it try to use a protected mode one by taking the address of the interrupt via 0x210 service (get_pm_exception_handler function) and checking the result of the operation via carryflag (test_int31 procedure). If that fails, it fallbacks into real mode. In the test_int31 the flag is not passed explicity as a parameter but pushed on the stack:

pushf
call test_int31

In the djgpp_exception_toggle there's a comment:

{ Windows 2000 seems to not set carryflag on func 0x210 :( PM }

and a line that make the trick:

     if (_os_trueversion  $532) and get_pm_exception_handler(i,_except) then

but I have the strong suspect that in this case Windows is blamed for nothing. Indeed, as you can see in the r152, where it is added the stdcall declaration to the test_int31 to deal proper with the flag parameter, the above workaround was previous present. So I removed the chunk:

(_os_trueversion $532)

that prevents NT-system to use protected mode handler even if it can, and as a result all the call to the signal(arg1,arg2) procedure in the compiler code requires a more strictly compliance in the 2nd argument: the declaration of the funtion or procedure whose address is there passed must includes the correct statement, i.e. cdecl.

Marco.