1. 02 Nov, 2016 4 commits
  2. 27 Oct, 2016 1 commit
  3. 26 Oct, 2016 1 commit
  4. 23 Oct, 2016 1 commit
  5. 09 Oct, 2016 1 commit
    • Moritz Angermann's avatar
      Do not segfault if no common root can be found · bcd34451
      Moritz Angermann authored
      When trying to profile a plugin, ghc mysteriously segfaulted.  Upon
      closer examination the segfault happend due to a `->prevStack` lookup
      on a NULL pointer.
      A new CostCentre: Unknown is introduced that is set, if ccsapp and
      ccsfn are of equal depth (e.g. 0), and do not have a common CostCentre
      in their stacks.
      Reviewers: bgamari, simonmar, austin, erikd
      Reviewed By: simonmar
      Subscribers: Phyx, thomie
      Differential Revision: https://phabricator.haskell.org/D2551
  6. 01 Sep, 2016 1 commit
    • Tamar Christina's avatar
      Added support for deprecated POSIX functions on Windows. · e5ecb201
      Tamar Christina authored
      With the introduction of 8.0.1 We've stopped supporting in GHCi
      the use of POSIX functions under their deprecated names on Windows.
      This to be compatible with object and libraries from the most
      popular compilers on the platform (Microsoft and Intel compilers).
      However this brings a confusing disparity between the compiled and
      interpreted behavior since MingW-W64 does support the deprecated names.
      Also It seems clear that package writers won't update their packages to
      properly support Windows. As such I have added redirects in the RTS
      for the deprecated functions as listed on
      This won't export the functions (as in, they won't be in the symbol table
      of compiled code for the RTS.) but we inject them into the symbol table
      of the dynamic linker at startup.
      Test Plan:
      make test TEST="ffi017 ffi021"
      Reviewers: thomie, simonmar, RyanGlScott, bgamari, austin, hvr, erikd
      Reviewed By: simonmar, bgamari
      Subscribers: RyanGlScott, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2500
      GHC Trac Issues: #12209, #12497, #12496
  7. 05 Jul, 2016 2 commits
  8. 04 Jul, 2016 1 commit
  9. 01 Jul, 2016 2 commits
  10. 27 Jun, 2016 1 commit
  11. 26 Jun, 2016 1 commit
  12. 13 Jun, 2016 1 commit
    • Tamar Christina's avatar
      Add thin library support to Windows too · 5cee88d7
      Tamar Christina authored
      Code already existed in the RTS to add thin library support for non-Windows
      operating systems. This adds it to Windows as well.
      ar thin libraries have the exact same format as normal archives except they
      have a different magic string and they don't copy the object files into the
      Instead each header entry points to the location of the object file on disk.
      This is useful when a library is only created to satisfy a compile time dependency
      instead of to be distributed. This saves the time required for copying.
      Test Plan: ./validate and new test T11788
      Reviewers: austin, bgamari, simonmar, erikd
      Reviewed By: bgamari, simonmar
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2323
      GHC Trac Issues: #11788
  13. 12 Jun, 2016 1 commit
    • Tamar Christina's avatar
      Fix incorrect calculated relocations on Windows x86_64 · b40e1b4c
      Tamar Christina authored
      See #12031 for analysis, but essentially what happens is:
      To sum up the issue, the reason this seems to go wrong is because
      of how we initialize the `.bss` section for Windows in the runtime linker.
      The first issue is where we calculate the zero space for the section:
      zspace = stgCallocBytes(1, bss_sz, "ocGetNames_PEi386(anonymous bss)");
      sectab_i->PointerToRawData = ((UChar*)zspace) - ((UChar*)(oc->image));
      UInt32 PointerToRawData;
      This means we're stuffing a `64-bit` value into a `32-bit` one. Also `zspace`
      can be larger than `oc->image`. In which case it'll overflow and
      then get truncated in the cast.
      The address of a value in the `.bss` section is then calculated as:
      addr = ((UChar*)(oc->image))
           + (sectabent->PointerToRawData
           + symtab_i->Value);
      If it does truncate then this calculation won't be correct (which is what is happening).
      We then later use the value of `addr` as the `S` (Symbol) value for the relocations
      S = (size_t) lookupSymbol_( (char*)symbol );
      Now the majority of the relocations are `R_X86_64_PC32` etc.
      e.g. They are guaranteed to fit in a `32-bit` value.
      The `R_X86_64_64` introduced for these pseudo-relocations so they can use
      the full `48-bit` addressing space isn't as lucky.
      As for why it sometimes work has to do on whether the value is truncated or not.
      `PointerToRawData` can't be changed because it's size is fixed by the PE specification.
      Instead just like with the other platforms, we now use `section` on Windows as well.
      This gives us a `start` parameter of type `void*` which solves the issue.
      This refactors the code to use `section.start` and to fix the issues.
      Test Plan: ./validate and new test added T12031
      Reviewers: RyanGlScott, erikd, bgamari, austin, simonmar
      Reviewed By: simonmar
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2316
      GHC Trac Issues: #12031, #11317
  14. 05 Jun, 2016 1 commit
  15. 04 Jun, 2016 1 commit
    • Tamar Christina's avatar
      Refactor the SymbolName and SymbolAddr types to be pointers · b948a1da
      Tamar Christina authored
      Take the pointer notation out of the typedef such that it preserves the
      fact that these are pointers at the use site.
      Test Plan:
      ./validate on all platforms that use the runtime linker.
      For unix platforms please ensure `DYNAMIC_GHC_PROGRAMS=NO` is
       added to your validate file.
      Continuation of D2250
      Reviewers: austin, bgamari, simonmar, erikd
      Reviewed By: erikd
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2302
      GHC Trac Issues: #11816
  16. 03 Jun, 2016 2 commits
    • Tamar Christina's avatar
      Use useful names for Symbol Addr and Names in Linker.c · 079c1b8c
      Tamar Christina authored
      Replace `char*` and `void*` with `SymbolName` and `SymbolAddr` in
      `Linker.c`. Gives some useful information about what the variables are
      used for and also normalizes the types used in Mac, Linux and Windows
      Test Plan:
      ./validate on all platforms that use the runtime linker.
      For unix platforms please ensure `DYNAMIC_GHC_PROGRAMS=NO` is
       added to your validate file.
      This is a continuation from D2184
      Reviewers: austin, erikd, simonmar, bgamari
      Reviewed By: bgamari
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2250
      GHC Trac Issues: #11816
    • Tamar Christina's avatar
      Refactored SymbolInfo to lower memory usage in RTS · 37473722
      Tamar Christina authored
      Previously as part of #11223 a new struct `SymbolInfo` was introduced to
      keep track it the weak symbol status of a symbol.
      This structure also kept a copy of the calculated address of the symbol
      which turns out was useful in ignoring non-weak zero-valued symbols.
      The information was kept in an array so it means for every symbol two
      extra bytes were kept even though the vast majority of symbols are
      non-weak and non-zero valued.
      This changes the array into a sparse map keeping this information only
      for the symbols that are weak or zero-valued. This allows for a
      reduction in the amount of information needed to be kept while giving up
      a small (negligable) hit in performance as this information now has to
      be looked up in hashmaps.
      Test Plan: ./validate on all platforms that use the runtime linker.
      For unix platforms please ensure `DYNAMIC_GHC_PROGRAMS=NO` is added to
      your validate file.
      Reviewers: simonmar, austin, erikd, bgamari
      Reviewed By: simonmar, bgamari
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D2184
      GHC Trac Issues: #11816
  17. 24 May, 2016 1 commit
    • Erik de Castro Lopo's avatar
      Runtime linker: Break m32 allocator out into its own file · fe8a4e5d
      Erik de Castro Lopo authored
      This makes the code a little more modular and allows the removal of some
      CPP hackery. By providing dummy implementations of of the `m32_*`
      functions (which simply call `errorBelch`) it means that the call sites
      for these functions are syntax checked even when `RTS_LINKER_USE_MMAP`
      is `0`.
      Also changes some size parameter types from `unsigned int` to `size_t`.
      Test Plan: Validate on Linux, OS X and Windows
      Reviewers: Phyx, hsyl20, bgamari, simonmar, austin
      Reviewed By: simonmar, austin
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2237
  18. 22 May, 2016 1 commit
  19. 21 May, 2016 1 commit
    • Simon Marlow's avatar
      Enable checkProddableBlock on x86_64 · da3c1ebb
      Simon Marlow authored
      We've been seeing some memory corruption after using the linker, and I
      want to enable this to see if it catches anything.
      Test Plan:
      * validate
      * modified the linker_unload test to remove the performGC calls to use
        as a benchmark, saw no significant difference after this change.
      Reviewers: bgamari, erikd, austin
      Reviewed By: austin
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2245
  20. 16 May, 2016 1 commit
  21. 11 May, 2016 1 commit
  22. 04 May, 2016 1 commit
  23. 28 Apr, 2016 1 commit
  24. 17 Apr, 2016 2 commits
    • Erik de Castro Lopo's avatar
      Linker: Clean up #if USE_MMAP usage · 177aec69
      Erik de Castro Lopo authored
      Test Plan:
       - Run tests on x86_64/linux, x86_64/darwin and powerpc/linux
       - Cross compile rts/Linker.c with the i686-w64-mingw32-gcc and
         x86_64-w64-mingw32-gcc Linux to Windows cross-compilers.
      Reviewers: hvr, austin, thomie, bgamari, simonmar, Phyx
      Reviewed By: Phyx
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1437
    • Tamar Christina's avatar
      Add Windows import library support to the Runtime Linker · 97f2b164
      Tamar Christina authored
      Import libraries are files ending in `.dll.a` and `.lib` depending on which
      compiler creates them (GCC, vs MSVC).
      Import Libraries are standard `archive` files that contain object files.
      These object files can have two different formats:
      1) The normal COFF Object format for object files
          (contains all ascii data and very little program code, so do not
           try to execute.)
      2) "short import" format which just contains a symbol name and
         the dll in which the symbol can be found.
      Import Libraries are useful for two things:
      1) Allowing applications that don't support dynamic linking to
         link against the import lib (non-short format) which then
         makes calls into the DLL by loading it at runtime.
      2) Allow linking of mutually recursive dlls. if `A.DLL` requires
         `B.DLL` and vice versa, import libs can be used to break the cycle
         as they can be created from the expected exports of the DLLs.
      A side effect of having these two capabilities is that Import libs are often
      used to hide specific versions of DLLs behind a non-versioned import lib.
      e.g. GCC_S.a (non-conventional import lib) will point to the correct
      `libGCC` DLL. With this support Windows Haskell files can now just link
      to `-lGCC_S` and not have to worry about what the actual name of libGCC is.
      Also third party libraries such as `icuuc` use import libs to forward to
      versioned DLLs. e.g. `icuuc.lib` points to `icuuc51.dll` etc.
      Test Plan:
      Two new tests added T11072gcc T11072msvc
      Two binary files have been added to the test folder because the "short"
      import library format doesn't seem to be creatable via `dlltool`
      and requires Microsoft's `lib.exe`.
      Reviewers: bgamari, RyanGlScott, erikd, goldfire, austin, hvr
      Reviewed By: RyanGlScott, erikd
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1696
      GHC Trac Issues: #11072
  25. 15 Apr, 2016 1 commit
  26. 11 Apr, 2016 1 commit
  27. 10 Apr, 2016 1 commit
    • 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
  28. 07 Mar, 2016 1 commit
    • niteria's avatar
      Reduce fragmentation from m32_allocator · 82e36edc
      niteria authored
      This patch brings in two improvements:
      a) m32_allocator will now reuse the pages that are no longer
      used by anyone else.
      b) m32_allocator will preallocate the "filling" area,
      so that the pages it allocates end up as a big chunk
      instead of being allocated on demand in random places,
      fragmenting the precious lower 2G address space.
      Test Plan: testsuite - 3 tests failing with substTy asserts
      Reviewers: ezyang, austin, bgamari, erikd, hsyl20, simonmar
      Reviewed By: hsyl20, simonmar
      Subscribers: hvr, thomie
      Differential Revision: https://phabricator.haskell.org/D1976
  29. 02 Feb, 2016 1 commit
    • Tamar Christina's avatar
      Fix Windows build after D1874 · 01c587c0
      Tamar Christina authored
      Windows uses wchar_t* for paths. The code committed won't compile for
      Windows as the types are incorrect and the types in the branches of the
      ternary operator aren't consistent.
      Test Plan: ./validate --fast
      Reviewers: austin, rwbarton, erikd, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1878
  30. 01 Feb, 2016 2 commits
  31. 25 Jan, 2016 1 commit
  32. 14 Jan, 2016 1 commit
    • Tamar Christina's avatar
      Remove lookup of sections by name instead use the index numbers as offsets · 49e414a7
      Tamar Christina authored
      This patch comes from @awson
      Playing with `-fsplit-sections` on Windows I've found a pile of ancient
      (it was borrowed from Hugs interpreter code and I don't even know when
      was it created), absolutely redundant and plain wrong code in RTS linker.
      Technically it is a bug, but it doesn't break things when used with
      current Windows binutils with no special linker scripts involved.
      OTOH, it slows down runtime linker on Windows noticeably and thus can
      be considered as a performance bug.
      The nice side-effect for existing users is that GHCi now loads compiled
      object code much faster on Windows.
      More specifically, sections were being looked up by name by doing a loop
      over all sections until the section with the given name is found.
      The new approach uses the section index and finds the section in O(1) time
      based on information gathered when we originally processed the section
      Test Plan: ./validate (was run on GHC x86)
      Reviewers: austin, awson, erikd, thomie, bgamari
      Reviewed By: thomie, bgamari
      Subscribers: awson, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D1773
      GHC Trac Issues: #11388