[GHC] #11223: Runtime linker performs eager loading of all object files

[GHC]

#11223: Runtime linker performs eager loading of all object files
-------------------------------------+-------------------------------------
        Reporter:  Phyx-             |                Owner:  Phyx-
            Type:  task              |               Status:  patch
        Priority:  normal            |            Milestone:  8.2.1
       Component:  Runtime System    |              Version:  7.10.3
  (Linker)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  crash                              |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #10726 #11317     |  Differential Rev(s):  Phab:D1805
  #11748                             |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"90538d86af579595987826cd893828d6f379f35a/ghc"
 90538d86/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="90538d86af579595987826cd893828d6f379f35a"
 Change runtime linker to perform lazy loading of symbols/sections

 The Runtime Linker is currently eagerly loading all object files on all
 platforms which do not use the system linker for `GHCi`.

 The problem with this approach is that it requires all symbols to be
 found.  Even those of functions never used/called. This makes the number
 of libraries required to link things like `mingwex` quite high.

 To work around this the `rts` was relying on a trick. It itself was
 compiled with `MingW64-w`'s `GCC`. So it was already linked against
 `mingwex`.  As such, it re-exported the symbols from itself.

 While this worked it made it impossible to link against `mingwex` in
 user libraries. And with this means no `C99` code could ever run in
 `GHCi` on Windows without having the required symbols re-exported from
 the rts.

 Consequently this rules out a large number of packages on Windows.
 SDL2, HMatrix etc.

 After talking with @rwbarton I have taken the approach of loading entire
 object files when a symbol is needed instead of doing the dependency
 tracking on a per symbol basis. This is a lot less fragile and a lot
 less complicated to implement.

 The changes come down to the following steps:

 1) modify the linker to and introduce a new state for ObjectCode:
    `Needed`.  A Needed object is one that is required for the linking to
    succeed.  The initial set consists of all Object files passed as
    arguments to the link.

 2) Change `ObjectCode`'s to be indexed but not initialized or resolved.
    This means we know where we would load the symbols,
    but haven't actually done so.

 3) Mark any `ObjectCode` belonging to `.o` passed as argument
    as required: ObjectState `NEEDED`.

 4) During `Resolve` object calls, mark all `ObjectCode`
    containing the required symbols as `NEEDED`

 5) During `lookupSymbol` lookups, (which is called from `linkExpr`
    and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded
    `ObjectCode` then load the `ObjectCode` on demand and return the
    address of the symbol. Otherwise produce an unresolved symbols error
    as expected.

 6) On `unloadObj` we then change the state of the object and remove
    it's symbols from the `reqSymHash` table so it can be reloaded.

 This change affects all platforms and OSes which use the runtime linker.
 It seems there are no real perf tests for `GHCi`, but performance
 shouldn't be impacted much. We gain a lot of time not loading all `obj`
 files, and we lose some time in `lookupSymbol` when we're finding
 sections that have to be loaded. The actual finding itself is O(1)
 (Assuming the hashtnl is perfect)

 It also consumes slighly more memory as instead of storing just the
 address of a symbol I also store some other information, like if the
 symbol is weak or not.

 This change will break any packages relying on renamed POSIX functions
 that were re-named and re-exported by the rts. Any packages following
 the proper naming for functions as found on MSDN will work fine.

 Test Plan: ./validate on all platforms which use the Runtime linker.

 Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr

 Reviewed By: erikd

 Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar,
              rwbarton, #ghc_windows_task_force

 Differential Revision: https://phabricator.haskell.org/D1805

 GHC Trac Issues: #11223
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11223#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler