• Tamar Christina's avatar
    Change runtime linker to perform lazy loading of symbols/sections · 90538d86
    Tamar Christina authored
    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
T11223_simple_duplicate_lib.stderr.normalised-mingw32 996 Bytes