#3654: Mach-O GHCi linker lacks support for a range of relocation entries
--------------------+-------------------------------------------------------
Reporter: chak | Owner:
Type: bug | Status: new
Priority: normal | Component: Runtime System
Version: 6.13 | Severity: normal
Keywords: | Testcase:
Os: MacOS X | Architecture: Unknown/Multiple
--------------------+-------------------------------------------------------
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 protected]>
* 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 `[email protected]`:
[http://www.haskell.org/pipermail/cvs-ghc/2009-November/050941.html]
[http://www.haskell.org/pipermail/cvs-ghc/2009-October/050893.html]
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3654>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
