Dynamically loading and unloading (C) object files

[Edsko de Vries]

Ok, great. We are only loading object files from C code, not Haskell
code -- we use the GHC API for that. And we're not using *anything*
concurrently when it comes to GHC, so that should be okay too. I've
been experimenting more with this and it seems to work okay :)

Will let you know if we come across any problems.

Edsko

On Tue, Nov 5, 2013 at 8:51 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 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
>>
>