wolfgang.thaller at gmx.net
Sun Aug 1 19:39:36 EDT 2004
>> 7) Devise a way of telling GHC that a foreign import is imported from
>> DLL (for Windows); something like __declspec(dllimport) in Windows C
>> compilers. We should have thought of this before the FFI spec was
> Can you explain point 7?
> How is a foreign import from DLL different from a foreign import from
> statically linked files or from foreign import of a function pointer?
> Do you have to do something different to cause the DLL to be loaded or
> do you
> have to invoke the function using a different calling convention or
Hmmm... while trying to explain it I found out that I was wrong.
Linkers for Win32 do just enough to work around the basic problem with
Win32 DLLs for foreign calls to work without problems. The problem
still exists with variables imported from DLLs, and if you take the
address of an imported function, the pointer will actually point to
some stub code instead of the real thing. We can probably ignore this
Dynamically imported things must be accessed via an indirection, and
statically imported things *must not* be. A thing from a
statically-linked file is just a label; However, if we import that
thing from a DLL, this label is not defined. Instead, we get a label
__imp__foo, which points to *the address of* the imported thing. We
have to dereference it when we use it.
For imported functions, the import library contains a piece of stub
_foo: jmp *__imp__foo
... and that's what (mostly) solves the problem, because we can still
just call _foo. It doesn't work for imported data, but who imports data
Sorry for the confusion,
More information about the FFI