RFC: ghc's dynamic linker

[Mike Thomas]

Hi there.

> Ok, let's start with a possible API to the library I think you're asking
> for:
>
>    loadLibrary  :: FilePath -> IO ()

"loadLibrary" is probably not a good choice as there is a Win32 function
"LoadLibrary" which deals specifically with DLL's as opposed to object files
which is the kind of file (or modifications thereof) that I understand this
thread to be about.
.....
> Summary: extending GHC's dynamic linker to be able to slurp in the
> symbol table from the currently running binary would be useful, and is a
> good bite-sized GHC hacker task.  I can't guarantee that we'll get
> around to it in a timely fashion, but contributions are, as always,
> entirely welcome...

By way of reference:

I have been working recently on the Mingw32 version of Gnu Common Lisp which
has a cross platform system of dynamically compiling and loading object
modules (ie the Common Lisp "compile-file" and "compile" functions).

There are two alternative pathways for this at present:

1. The old way (which I believe originally came from GNU Emacs) - During the
early stages of building the GCL system, a program called "rsym" is run on
the execuatable to produce a list of symbols and addresses.  These data are
then loaded into an appropriate data structure in the running system and the
image is saved again.  When "compile" is called on a function it is compiled
to C, that C is in turn compiled to an object file by the local C compiler
and then certain symbolic information needed by GCL is literally appended to
the object file without further ado.  Specially written linking code slurps
up the modified object file and links it into the running GCL system.  This
works on a number of platforms.

2. The BFD way - Similar stuff is done but via the BFD library.  This works
on many Debian platforms (about 16 I believe) including 64 bits and
non-intel architectures.  The code is generic.  It does not work on Windows
as the BFD library seems to be missing functionality in that area.  I
believe that SGI might also be a problem too.  We hope to make this the
standard way of dynamically linking object files but I am caught by my own
lack of interest in and ignorance of how BFD works.

The source code (horrific stuff from many years of uncontrolled but
undoubtedly clever hackery) is available from CVS at:

http://savannah.gnu.org/projects/gcl/

I can refer you to the appropriate bits if you are interested.

Naturally it is all GNU copylefted and therefore incompatible with GHC, but
it could be used as a road map by interested parties.

Cheers

Mike Thomas.