Ideas and questions about dynamic linking

[Simon Marlow]

On 23/12/2009 08:43, Howard B. Golden wrote:
> I've been thinking about the dynamic linking proposal and I have some
> ideas and questions. I am trying to clarify (in my mind) the
> requirements / like-to-haves.
>
> Q1. Is LGPL code acceptable? If so, you might want to consider gmodule
> from glib (see http://library.gnome.org/devel/glib/unstable/glib-
> Dynamic-Loading-of-Modules). According to their documentation, they've
> already done all the work to make dynamic linking work on many
> platforms.

I only took a quick look at it.  As far as I can tell, it provides a 
system-independent layer over the top of whatever dynamic linking is 
provided by the system, much like our Linker API (although rather more 
polished).

I don't think this solves any of the immediate problems, and I don't 
think the benefits would be worth the LGPL price tag.

> Q2. How is dynamic linking related to GHCi interpretation? Will it ever
> be necessary to be able to link dynamically _to_ interpreted code
> objects? (Linking _from_ interpreted code shouldn't be a problem.)

No, we don't need to link compiled code to interpreted code. GHC's 
compilation manager ensures that compiled code only refers to other 
compiled code.

> Q3. Would it be acceptable to require compilation with PIC and the use
> of the system linker to turn modules into shared objects in order to use
> dynamic linking? Is it necessary for GHCi to be able to load .o files
> directly?

It's necessary for GHCi to be able to load compiled object files. But 
that doesn't mean we have to load the .o's directly, it may be possible 
to convert them into .so's first.  The only problems here are whether 
this is an unacceptable overhead, and the details of where the files go, 
how they get cleaned, etc.

As for PIC by default, I don't know the answer - someone needs to do 
some experimentation here.  We don't have recent measurements of the 
overhead of PIC, it may well be small enough to enable by default. Note 
the overhead on x86_64 is lower than on x86, so we should measure on both.

> Q4. Currently the Haskell linker (rts/Linker.c) maintains a symbol
> table. Why is this necessary? What would happen if the Haskell code
> called the system's symbol lookup (e.g., dlsym on POSIX or
> g_module_symbol from gmodule)?

The RTS is not currently dynamically linked, so dlsym() doesn't know the 
address of RTS symbols. If/when we switch to a dynamically-linked GHCi, 
that symbol table can go away (yay!).

> Q5. Are there any platforms that GHCi runs on that don't support shared
> libraries and dynamic linking?

The three object formats we support in the linker (ELF, MACH-O, COFF) 
all have dynamic linking support, so I think the answer is no.

Cheers,
	Simon