Rolling your own dynamic linker

[Duncan Coutts]

On Fri, 2009-10-30 at 19:31 +1100, Manuel M T Chakravarty wrote:

> This made Roman and me wonder whether it wouldn't be possible to use  
> dynamic libraries and dlopen() instead of the current setup.  AFAIK  
> GHC can now generate dynamic libraries on Linux and somebody was  
> working on fixing them for MacOS, too.  If GHC can create dynamic  
> libraries, what else would prevent us from using them for dynamically  
> loaded code (in ghci, TH, etc)?  I can immediately see a number of  
> benefits of this approach:

Using dynamic libs for packages for ghci is certainly a good idea.

However to use the system linker everywhere you must abandon having ghci
load .o files since the dlopen() call does not understand them. That
means you can not use the current system where we ghc --make and then
use ghci to load the compiled .o files.

We'd have to investigate alternative options. Perhaps we could have
ghc/ghci build each .o into a separate .so/.dynlib or link them all into
one .so/.dynlib before loading (which means we must always compile -fPIC
and that has a non-zero cost). The same goes for .o files from
helper/wrapper C code. It doesn't seem especially pretty.

One could also imagine a system where we can load compiled code from ghc
but not arbitrary .o files (imagine something like the final cmm stage
being serialised/deserialised followed by in-memory jit). That'd would
not help your example of special dtrace symbols of course since those
are in external .o files from the C compiler. You'd have to compile that
into a .so/.dynlib lib first.

Duncan