I've merged this, but I think a better solution might be for -fPIC to
generate code that calls a different version of newCaf (i.e. newDynCaf).
Well, we've got three different ways to treat a CAF now:
A) garbage collect them as usual - what newCAF used to do, and what it still does most of the time
B) retain them - what newCAF does now when we are in dynamically-linked ghci
C) retain them and maybe revert them later - what newDymCAF does.
Most of the time, CAFs from dynamic libraries should get treatment A, only in GHCi they should get treatment B. C is really reserved for .o files, we probably don't want to "revert" unsafePerformIO cafs in GHCi or the libraries.
So even if we made -fPIC call a different new*CAF, we'd still need the same checks for GHCi. It's not making things simpler, it only helps us to avoid retaining CAFs in the main program.
Also, it's still possible on Mac OS X to link -fPIC code statically, and on PowerPC64 Linux, all code is position independent, so you don't need -fPIC. I'm reluctant to add more GHC-specific code generation differences that would prevent that.
How bad is it to retain CAFs in GHCi? I think it shouldn't cause a problem in an interactive program like GHCi, where most things are meant to stick aroud anyway. I don't think there are any big CAFs used in GHCi during initialisation that can be collected when initialisation is done?
Iff we decide it's bad, then we'll want to do something about it - so far I can think of two things:
a) generate different calls for -fPIC. Ugly because it makes -fPIC more special than it is on some platforms.
b) check the CAF's address. Ugly in principle, but not as bad as the address space checks we used to have before GHC 6. I think it can even be done portably (based only on the assumption that no dynamic libraries are loaded _between_ the executable's code and data sections), because we are in a very controlled situation here. The CAF is in the data section and contains a pointer to the text section of the same executable/dylib. That way we wouldn't even need to get access to etext and friends again:
// returns true if caf is in the main executable
if(caf->info < caf) // if text comes before data
return caf > &someTextObjectInExecutable && caf->info < &someDataObjectInExecutable;
else // else data comes before text
return caf < &someTextObjectInExecutable && caf->info > &someDataObjectInExecutable;
Cheers,
Wolfgang
_______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
