...

...

...

...

"Kevin" == Kevin S Millikin writes:

Kevin> I have. Or rather, I haven't. The example in Section 11.4 Kevin> of the User's Guide doesn't work. The call to Kevin> "startupHaskell()" hangs forever (or as long as I'm willing Kevin> to wait). Kevin> It works fine when the exact same call to startupHaskell is Kevin> linked statically. I've done some rooting around in the GHC sources and tracing in a debugger, and I know more about *where* it goes wrong. To recap: the example of Haskell code in a Windows DLL in Section 11.4 of the User's Guide does not work. The call to startupHaskell(...) does not return. (On Windows NT, using GHC 5.04.2). startupHaskell is in rts/RtsStartup.c. It calls a bunch of stuff, then calls startVirtTimer(...), which never returns. startVirtTimer is in rts/Itimer.c. It calls some stuff, then calls the Windows SDK function timeSetEvent(...). timeSetEvent is in the multimedia DLL WINMM.DLL. Here's where it gets fuzzy. Eventually, WINMM.DLL calls into KERNEL32.DLL. Eventually that calls into NTDLL.DLL. NTDLL issues the x86 instruction: int 2Eh Which is an interrupt. The debugger can't tell me where this tries to go; it never gets back. Anyone have any idea what this interrupt is? Is it a callback to Haskell? Since this is in one of the Windows NT system DLLs, it's tempting to call it an "OS" problem, but it doesn't feel like it. Curiously, the exact same code continues to work perfectly when the code that contains the call to startupHaskell is linked statically (and with an explicit call to DllMain). Perhaps someone with more knowledge of Windows DLLs has some idea. Or possibly, what is the call to startVirtTimer doing? Would it be possible to replace it with some alternative that would work when linked either statically or dynamically? -- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture (952)829-5864 x. 162 http://www.atcorp.com