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
interface files.
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.
Ben.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
