dynamic ForeignLabel and DLLs
wolfgang.thaller at gmx.net
Thu Feb 19 22:37:23 EST 2004
> How do you know for a given foreign call whether it is dynamic or not?
I don't. The linker does, it removes the import stub if it is
unnecessary. For data references, the imported pointer is replaced by a
const_data pointer to the data, so an extra indirection stays, but I
guess we can afford that.
> By all means adopt what's there, or add another form of labelDynamic
> which suits your situation better. We don't want to throw away
> labelDynamic, even though it isn't used, because it imposes some
> requirements on the rest of the compiler that we don't want to forget
> about in case we ever revisit DLL support.
I added a new function that returns True whenever labelDynamic returns
true (which I think it never does, currently), or when the label is a
foreign label. Every foreign label *could* be imported from a DLL, so I
have to do this.
I couldn't use deRefDLL because it's outside the NCG monad. I needed to
call addImportNat to record which "dynamic linker stubs" I have to
The code I committed yesterday should work for the standard case where
all the Haskell code is in the main executable, but at least some of
the foreign code that it calls is in dynamic libraries. For real DLL
support, I'd have to generate position independent code, which isn't
that easy on PPC, as getting the current program counter/instruction
pointer is relatively expensive (involves a fake subroutine call). It's
OK to do it at the beginning of a top-level proc, but not for every
data reference. I'd probably need some extra info from the codeGen to
do this properly (like, "will this proc ever be called directly, or
will it always be called via a computed goto?", "where will it be
called from?" etc.). But this can wait, I won't tackle this right away,
as it should be possible to generate DLL-capable code via C.
P.S.: Adding a BaseReg on PowerPC _did_ reduce the code size noticably.
More information about the Cvs-ghc