Mach-O GHCi linker lacks support for a range of relocation entries
The Mach-O code of the GHCi linker
rts/Linker.c lacks support for a range of relocation entries. It used to silently ignore many of them. The following patch makes it barf() when it encounters an unsupported entry:
Wed Nov 11 13:07:12 EST 2009 Manuel M T Chakravarty <email@example.com> * Barf on unhandled Mach-O relocations in the ghci linker - It might be worthwhile to MERGE this to 6.12, BUT somebody should validate it on PPC/Mac OS X first.
Moreover, at least one entry type —i.e.,
GENERIC_RELOC_LOCAL_SECTDIFF— is not correctly implemented.
This is an unsatisfactory situation as the transition from Mac OS X 10.5 (Leopard) to 10.6 (Snow Leopard) showed. In that case, changes in
ld suddenly created a so far unsupported entry type. This was before the above patch; so, the ignored entry led to an incorrectly relocated image, which crashed GHCi with a SIGBUS.
Instead of trying to improve the dynamic linker, IMHO, GHC should use dynamic libraries with
dlopen() and leave the implementation of dynamic linking to the OS vendor. This has a number of advantages:
- The RTS gets smaller & simpler, and we eliminate a whole category of potentially tricky bugs.
- Dynamically loaded code can use dtrace probes (and other features requiring linker trickery).
- Packages that GHC links to, don't need to be in memory twice (once statically and once dynamically linked).
- Potential performance advantage due to optimisations in the OS' dynamic linker.
The main obstacle with using dynamic libraries and
dlopen() appears to be the required on-the-fly conversion of GHC-generated object files into dynamic libraries. Otherwise, SimonM says that it is already possible to compile GHC itself dynamically-linked at the moment that the linker will then use
dlopen() for loading packages.
More details are in the following thread on