dynamic ForeignLabel and DLLs

[Simon Marlow]

> What's the current status of the is_dynamic parameter to 
> mkForeignLabel 
> and deRefDLL in MachCodeGen.hs? The codeGen seems to always 
> pass False for is_dynamic.

The DLL support has bitrotted in lots of ways.  This is a bit sad, but
there are only so many hours in the day.

The comment by deRefDLL is still valid.  However its possible that we're
not calling deRefDLL in the right places any more.  In any case, it
should really go in the same place as we expand GlobalRegs, because it
has the same kind of transform-Cmm-before-NCG flavour to it.  Since it's
not useful for you, I'll probably just remove it and replace it with a
panic when not opt_Static.

We'll still keep the labelDynamic property on a CLabel though, which
means that mkForeignLabel needs the is_dynamic flag.  labelDynamic
probably isn't exactly what you want, because it assumes that different
packages are in different dynamic libraries, so it returns True if the
label refers to something in another package and not opt_Static.

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.

> The reason I'm asking is that I need something that is 
> almost, but not 
> quite, like deRefDLL and friends in order to correctly 
> support foreign 
> imported pointers on Mac OS X:
> 
> foreign import ccall unsafe "&foo" foo :: Ptr Int
> 
> I basically need a way to find out whether some CmmLit (CmmLabel lbl) 
> _might_ come from a dynamic library. False positives carry only a 
> slight performance penalty, so I wouldn't mind treating all 
> ForeignLabels as "dynamic".
> I won't use deRefDLL, which is slightly wrong for my 
> purposes, but just 
> handle it when I generate code for a CmmLit.

How do you know for a given foreign call whether it is dynamic or not?

> I could of course just add my own version of labelDynamic to CLabel, 
> but I'd prefer my solution to fit in with the general framework.

Cheers,
	Simon