Mach-O GHCi linker lacks support for a range of relocation entries

[chak]

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 <chak@cse.unsw.edu.au>
  * 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 cvs-ghc@haskell.org:

 http://www.haskell.org/pipermail/cvs-ghc/2009-November/050941.html  http://www.haskell.org/pipermail/cvs-ghc/2009-October/050893.html

[mnislaih]

I really hope this gets fixed for 6.12

[simonmar]

This ticket goes off topic a bit. Is it a report about the lack of support for certain relocations, or a feature request for the use of the system dynamic linker in GHCi? Regarding the latter, I think we should move the discussion elsewhere (cvs-ghc or glasgow-haskell-users). Let's leave this ticket for the lack of support for relocations, which may be subsumed by dynamic linking if that happens.

Replying to mnislaih:

I really hope this gets fixed for 6.12

I'm not sure which part of the ticket you're referring to: using the system dynamic linker is definitely not going to happen for 6.12, and the missing relocation types almost certainly aren't affecting you, are they? If they are affecting you, we should make this bug a high prio.

[mnislaih]

Replying to simonmar:

Replying to mnislaih:

I really hope this gets fixed for 6.12

I'm not sure which part of the ticket you're referring to: using the system dynamic linker is definitely not going to happen for 6.12, and the missing relocation types almost certainly aren't affecting you, are they? If they are affecting you, we should make this bug a high prio.

Nevermind. I just wanted to show my support to ghci 6.12 working on Snow Leopard, which as I understood after a quick read, motivated this ticket. But on a second read I see that the new unsupported entry type has been implemented, and ghci will continue working in snow leopard.

[chak]

Replying to simonmar:

This ticket goes off topic a bit. Is it a report about the lack of support for certain relocations, or a feature request for the use of the system dynamic linker in GHCi? Regarding the latter, I think we should move the discussion elsewhere (cvs-ghc or glasgow-haskell-users). Let's leave this ticket for the lack of support for relocations, which may be subsumed by dynamic linking if that happens.

Yes, the ticket is about the unsupported relocations and other bugs in the dynamic linker for Mach-O. But IMHO using the system linker is the best way to fix those bugs. (At least, I'd be surprised if anybody would sit down and implement the missing pieces. Personally, I certainly would rather invest the time moving towards using the system linker.)

[chak]

Replying to mnislaih:

Never mind. I just wanted to show my support to ghci 6.12 working on Snow Leopard, which as I understood after a quick read, motivated this ticket. But on a second read I see that the new unsupported entry type has been implemented, and ghci will continue working in snow leopard.

I implemented one of the missing relocations, which prevented GHCi to work on Snow Leopard at all (as it was triggered when loading integer-gmp). However, there are more relocations missing. And, to be honest, I didn't even implement the one that I did add properly. To do it, one would need to implement coalesced sections, which AFAIK are completely ignored at the moment. The Mach-O ABI reference has the following to say:

These are important static-linking variants of the symbol type and attributes:

Regular sections. In a regular section, only one definition of an external symbol may exist in intermediate object files. The static linker returns an error if it finds any duplicate external symbol definitions.

Coalesced sections. In the final product, the static linker retains only one instance of each symbol defined in coalesced sections. To support complex language features (such as C++ vtables and RTTI) the compiler may create a definition of a particular symbol in every intermediate object file. The static linker and the dynamic linker would then reduce the duplicate definitions to the single definition used by the program.

Coalesced sections with weak definitions Weak symbol definitions may appear only in coalesced sections. When the static linker finds duplicate definitions for a symbol, it discards any coalesced symbol definition that has the weak definition attribute set (see nlist). If there are no non-weak definitions, the first weak definition is used instead. This feature is designed to support C++ templates; it allows explicit template instantiations to override implicit ones. The C++ compiler places explicit definitions in a regular section, and it places implicit definitions in a coalesced section, marked as weak definitions. Intermediate object files (and thus static archive libraries) built with weak definitions can be used only with the static linker in Mac OS X v10.2 and later. Final products (applications and shared libraries) should not contain weak definitions if they are expected to be used on earlier versions of Mac OS X.

I guess we haven't run into problems with that yet only because few people load packages binding to C++ code into GHCi (on Mac OS X). Coalesced sections and the relocations types that are still missing will definitely not be in 6.12 and as I mentioned above, I believe we should work on using the system linker, instead of wasting time on replicating its functionality in subsequent releases.

[morrow]

What are the things that would need changing or doing to move ghci to exclusively use the system dynamic linker? What are the really problematic things (given the current implementation) that would need sorting out with respect to this?

[morrow]

To clarify, I mean s/Linker.c/dlfcn.h/, in addition to  3658

[simonmar]

Replying to morrow:

What are the things that would need changing or doing to move ghci to exclusively use the system dynamic linker? What are the really problematic things (given the current implementation) that would need sorting out with respect to this?

See  http://www.haskell.org/pipermail/cvs-ghc/2009-November/051196.html and Manuel's reply.

[PHO]

Add support for PPC_RELOC_LOCAL_SECTDIFF

[PHO]

Attached PPC_RELOC_LOCAL_SECTDIFF.patch solves problems like

ghc-stage2: internal error: Don't know how to handle this Mach-O scattered reloc
ation entry: object file /usr/pkgsrc/wip/ghc/work/ghc-6.12.2/libraries/ghc-prim/
dist-install/build/HSghc-prim-0.2.0.0.o; entry type 15; address 0x458a0

but I prefer using dlopen() instead of our own dynamic linker to simplify things.

[igloo]

Thanks for the patch; we'll take a look.

[igloo]

Thanks, I've applied PPC_RELOC_LOCAL_SECTDIFF.patch - but I think this ticket is about more than just that, so I'm leaving it open.