Windows DLLs should be working.
Ben.Lippmeier at anu.edu.au
Mon Jan 11 20:20:39 EST 2010
Duncan Coutts wrote:
> On Sun, 2010-01-10 at 17:24 +1100, Ben Lippmeier wrote:
>> Windows DLLs should be working now.
> Huzza. Great work Ben.
> So what was the solution in the end to the problem of the cross-module
> inlining and making intra vs inter DLL-calls?
The solution was to refactor the foreign call code to track the
packageIds of imported labels, and also put this information in the
For example, in the "integer-gmp" package, in the module
"GHC.Integer.GMP.Internals" there is an import:
foreign import prim "integer_cmm_plusIntegerzh" plusInteger#
:: Int# -> ByteArray# -> Int# -> ByteArray# -> (# Int#, ByteArray# #)
The code for plusInteger# is linked into the integer-gmp library, and
appears in libHSinteger-gmp-version.dll. Now, when we're compiling
GHC.Integer.GMP.Internals the renamer tags the plusInteger# label with
the package that it's from (integer-gmp). If code that uses this label
gets inlined into another package, we'll still know that the actual
implementation of plusInteger# is in libHSinteger-gmp-version.dll.
For ELF(Linux) and MachO(OSX) it doesn't matter. When we're compiling in
the "dyn" way on these platforms all foreign labels are taken to need
dynamic linkage, and the linker just works it out. On Windows, we have
to generate different code depending on whether a label needs dynamic
linkage or not, so we have to track what package each label comes from.
More information about the Cvs-ghc