Rolling your own dynamic linker

Manuel M T Chakravarty chak at cse.unsw.edu.au
Tue Nov 3 20:57:56 EST 2009


Simon Marlow:
> On 30/10/2009 08:31, 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)?
>
> You can compile GHC itself dynamically-linked at the moment, and  
> indeed the linker will then use dlopen() for loading packages.  We  
> don't ship GHC that way yet, because our binary distribution  
> infrastructure isn't capable of handling dynamically-linked binaries  
> at install-time yet.  I think we should do this in the 6.14.1  
> timeframe; I plan to create a ticket just as soon as hackage comes  
> back up.

Great!

> The main sticking point with using dlopen() exclusively, as Duncan  
> pointed out, is that we need to link plain .o files in GHCi.  There  
> may be workarounds for this (e.g. calling gcc -shared on each one,  
> and perhaps using -fPIC by default), but someone needs to do some  
> investigation to see what will work here.  If there is a solution,  
> it's likely to be different on each platform.

Yes, but I think that's ok.  After all, the current .o loader is  
platform-dependent, too.

>> Apart from this larger design issue, I was wondering why the dynamic
>> linker silently ignores relocation entries that it doesn't grok? This
>> bug would have been very easy to fix had the linker complained about
>> unknown relocation entries. Unless there are any objections, I would
>> like to change the implementation to abort (or at least emit a  
>> warning)
>> in this situation. IMHO the Right Thing is to abort. If a relocation
>> entry is ignored, there is almost certainly a piece of code  
>> somewhere in
>> the loaded image that will crash the program. Ignoring that, appears
>> unwise.
>
> Yes, please do.  I wasn't aware we were silently ignoring unknown  
> relocations.

Ok.

Manuel



More information about the Cvs-ghc mailing list