PIC status

[Wolfgang Thaller]

>> 7) Devise a way of telling GHC that a foreign import is imported from 
>> a
>> DLL (for Windows); something like __declspec(dllimport) in Windows C
>> compilers. We should have thought of this before the FFI spec was
>> finalized...
>> [...]
>
> 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 
> both?

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 
problem...

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 
code:
_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 
anyway?.

Sorry for the confusion,

Wolfgang