Dynamically loading and unloading (C) object files

[Simon Marlow]

On 31/10/2013 18:06, Edsko de Vries wrote:
> Hi guys,
>
> We started experimenting with dynamically loading and unloading C
> object files (using the GHC API). I have a simple example with an
> object file exporting a single symbol "f"; I have two versions of the
> object file; in the first one, f is defined
>
> int f() {
>    return 1234;
> }
>
> The second one uses the value "4321" instead. I can dynamically load
> and unload these object files (using "linkObj" and "unlinkObj" from
> "ObjLink"). I can load the first, dynamically compile some Haskell
> code that imports this symbol, then upload this object file and load
> the second, and as long as I make sure that the Haskell code gets
> recompiled (perhaps a relink step suffices, haven't experimented an
> awful lot yet) it can then interact with the second object file.

So you're loading C code using linkObj, and then compiling some Haskell 
code that uses 'foreign import' to reference the C code?  That *should* 
be fine, but it's not a use-case that we have thought about.  I 
certainly wouldn't try to load Haskell code manually while also using 
the GHC API.

The RTS linker isn't thread-safe, so be careful about using the GHC API 
and calling linkObj etc. concurrently.

> All this is good news -- in fact, it is more than we had hoped for,
> because ghci does not allow dynamically unloading or loading any
> object files at all. Object files specified on the command line are
> handled in initDynLinker and the ghci top-level function doesn't even
> get to see them, and we cannot load object files from inside a ghci
> session.

Nobody asked for this, so we never implemented it :-)  It ought to be 
entirely reasonable to extend the GHC API to allow for loading and 
unloading of foreign object files, and to expose that functionality in GHCi.

Cheers,
Simon


> So that leads me to wonder: are there limitations that we should be
> aware of? Have I simply been lucky so far?
>
> Any points or suggestions for things to try would be appreciated,
>
> Edsko
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>