1. 18 Apr, 2016 2 commits
  2. 17 Apr, 2016 3 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
    • Andrew Farmer's avatar
      Check CCS tree for pointers into shared object during checkUnload · 36a0b6dc
      Andrew Farmer authored
      Prevent shared objects from being unloaded if cost centre stacks point
      at the object. This will prevent segfault in #11776, but also prevents
      objects from ever being unloaded when profiling. Pruning CCS tree will
      enable that in another diff.
      Test Plan: make TEST=linker_profiled, examine linker_profiled.run.stderr
      Reviewers: austin, simonmar, bgamari
      Reviewed By: simonmar, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2069
      GHC Trac Issues: #11776
    • 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
  3. 16 Apr, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Rework CC/CC_STAGE0 handling in `configure.ac` · 865602e0
      Herbert Valerio Riedel authored
      Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
      scheme use the `CC=...` style scheme.
      The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
      stage{1,2,3}, while having a separate _STAGE0 set of env-vars
      denote the bootstrap-toolchain flags/programs.
      This should be simpler, less confusing, and somewhat more in line with
      Autoconf's idioms (allowing us to reuse more of Autoconf rather than
      (re)inventing our own confusing non-standard m4 macros to do stuff that
      Autoconf could almost do already for us)
      Morever, expose CC_STAGE0 as a so-called "precious" variable.
      So now we can better control which bootstrapping gcc is used
      (by default the one used by the stage0 ghc, unless CC_STAGE0 is
      Some influential environment variables:
        CC_STAGE0   C compiler command (bootstrap)
        CC          C compiler command
        CFLAGS      C compiler flags
      Use these variables to override the choices made by `configure' or to
      help it...
  4. 15 Apr, 2016 2 commits
  5. 12 Apr, 2016 3 commits
    • Simon Marlow's avatar
      Allocate blocks in the GC in batches · f4446c5b
      Simon Marlow authored
      Avoids contention for the block allocator lock in the GC; this can be
      seen in the gc_alloc_block_sync counter emitted by +RTS -s.
      I experimented with this a while ago, and there was already
      commented-out code for it in GCUtils.c, but I've now improved it so that
      it doesn't result in significantly worse memory usage.
      * The old method of putting spare blocks on ws->part_list was wasteful,
        the spare blocks are now shared between all generations and retained
        between GCs.
      * repeated allocGroup() results in fragmentation, so I switched to using
        allocLargeChunk() instead which is fragmentation-friendly; we already
        use it for the same reason in nursery allocation.
    • Simon Marlow's avatar
      Cache the size of part_list/scavd_list (#11783) · 5c4cd0e4
      Simon Marlow authored
      After a parallel GC, it is possible to have a long list of blocks in
      ws->part_list, if we did a lot of work stealing but didn't fill up the
      blocks we stole.  These blocks persist until the next load-balanced GC,
      which might be a long time, and during every GC we were traversing this
      list to find its size.  The fix is to maintain the size all the time, so
      we don't have to compute it.
    • Simon Marlow's avatar
      Small simplification (#11777) · 83eb4fd9
      Simon Marlow authored
      DEAD_WEAK used to have a different layout, see
  6. 11 Apr, 2016 1 commit
  7. 10 Apr, 2016 4 commits
    • 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
    • Ben Gamari's avatar
      RtsFlags: Un-constify temporary buffer · 378091c9
      Ben Gamari authored
      Otherwise we get a const-ness mismatch when we free the buffer, which
      for some reason gcc 5.3 didn't notice.
    • wereHamster's avatar
      Remove spurious STG_UNUSED annotation · 6d7fda5e
      wereHamster authored
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2096
    • Simon Marlow's avatar
      Refactor comments about shutdown · 485608d3
      Simon Marlow authored
  8. 07 Apr, 2016 2 commits
  9. 04 Apr, 2016 1 commit
  10. 30 Mar, 2016 1 commit
  11. 29 Mar, 2016 3 commits
  12. 28 Mar, 2016 2 commits
    • Herbert Valerio Riedel's avatar
      Scrap DEC OSF/1 support · f911358b
      Herbert Valerio Riedel authored
      DEC OSF/1 (aka Tru64 UNIX) has been discontinued a few years ago already[1].
      This removes the undoubtedly bitrotten support for `OSOsf3 :: OS` from GHC's
      Support for `ArchAlpha :: Arch` may be removed at some later point, as there
      may still be users out there running a more or less recent Linux/alpha
      distribution on their more-than-a-decade old Alpha hardware...
       [1]: https://en.wikipedia.org/wiki/Tru64_UNIX
    • Herbert Valerio Riedel's avatar
      Scrap IRIX support · 0bca3f3a
      Herbert Valerio Riedel authored
      Long time ago, IRIX was way ahead of its time in the last century with
      its SMP capabilities of scaling up to 1024 processors and other features
      such as XFS or OpenGL that originated in IRIX and live on to this day in
      other operating systems.
      However, IRIX's last software update was in 2006 and support ended
      around 2013 according to [1], so it's considered an extinct platform by
      now. So this commit message is effectively an obituary for GHC's IRIX
      R.I.P. IRIX
       [1]: https://en.wikipedia.org/wiki/IRIX
  13. 27 Mar, 2016 1 commit
  14. 24 Mar, 2016 5 commits
    • Herbert Valerio Riedel's avatar
      Add NCG support for AIX/ppc32 · df26b955
      Herbert Valerio Riedel authored
      This extends the previous work to revive the unregisterised GHC build
      for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later)
      hardware, but the PPC32 instructions implemented in the PPC NCG
      represent a compatible subset of the POWER4 ISA.
      IBM AIX follows the PowerOpen ABI (and shares many similiarites with the
      Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF
      format (compared to ELF).
      This doesn't support dynamic libraries yet.
      A major limiting factor is that the AIX assembler does not support the
      `@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's
      assembler supports. Therefore we need to avoid emitting those. In case
      of numeric literals we simply compute the functions ourselves, while for
      labels we have to use local TOCs and hope everything fits into a 16bit
      offset (for ppc32 this gives us at most 16384 entries per TOC section,
      which is enough to compile GHC).
      Another issue is that XCOFF doesn't seem to have a relocation type for...
    • Herbert Valerio Riedel's avatar
      Avoid local label syntax for assembler on AIX · 343349df
      Herbert Valerio Riedel authored
      Unfortunately (for inline `__asm__()` uses), IBM's `as` doesn't seem to support
      local labels[1] like GNU `as` does so we need to workaround this when on AIX.
       [1]: https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol-Names
      Turns out this also addresses the long-standing bug #485
      Reviewed By: bgamari, trommler
      Differential Revision: https://phabricator.haskell.org/D2029
    • Ben Gamari's avatar
      Revert "Various ticky-related work" · ef653f1f
      Ben Gamari authored
      This reverts commit 6c2c853b which was
      supposed to be merged as individual commits.
    • Joachim Breitner's avatar
      Various ticky-related work · 6c2c853b
      Joachim Breitner authored
      this Diff contains small, self-contained changes as I work towards
      fixing #10613. It is mostly created to let harbormaster do its job, but
      feedback is welcome as well.
      Please do not merge this via arc; I’d like to push the individual
      patches as layed out here. I might push mostly trivial ones even without
      review, as long as the build passes.
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2014
    • archblob's avatar
      Close ticky profiling file stream after printing (#9405) · 2708c22b
      archblob authored
      Test Plan: T9405
      Reviewers: simonmar, austin, bgamari
      Reviewed By: simonmar, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2008
      GHC Trac Issues: #9405
  15. 21 Mar, 2016 1 commit
  16. 20 Mar, 2016 1 commit
  17. 11 Mar, 2016 2 commits
    • Sergei Trofimovich's avatar
      rts: fix threadStackUnderflow type in cmm · e46742f5
      Sergei Trofimovich authored
      stg_stack_underflow_frame had an incorrect
      call of C function 'threadStackUnderflow':
          ("ptr" ret_off) =
            foreign "C" threadStackUnderflow(
      Which means it's prototype is:
          void * (*) (W_, void*);
      While real prototype is:
          W_ (*) (Capability *cap, StgTSO *tso);
      The fix is simple. Fix type annotations:
          (ret_off) =
            foreign "C" threadStackUnderflow(
              MyCapability() "ptr",
              CurrentTSO "ptr");
      Noticed when debugged T9045 test failure
      on m68k target which distincts between
      pointer and non pointer return types
      (uses different registers)
      While at it noticed and fixed return types
      for 'throwTo' and 'findSpark'.
      Trac #11395
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
    • Erik de Castro Lopo's avatar
      rtx/posix/Itimer.c: Handle return value of `read` · 8626d76a
      Erik de Castro Lopo authored
      On Ubuntu libc's `read` function is marked with attribute
      `warn_unused_result` which was causing build failures on
      Test Plan: validate on Harbourmaster
      Reviewers: austin, hvr, bgamari
      Reviewed By: hvr, bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1993
      GHC Trac Issues: #11697
  18. 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
  19. 05 Mar, 2016 1 commit
  20. 27 Feb, 2016 1 commit
  21. 26 Feb, 2016 1 commit
  22. 25 Feb, 2016 1 commit
    • Peter Trommler's avatar
      testsuite: mark tests broken on powerpc64 · feb19eae
      Peter Trommler authored
      The following tests fail on powerpc64 and have a ticket.
      Mark those tests as expect_broken.
      Here are the details:
      The PowerPC native code generator does not support DWARF debug
      information. This is tracked in ticket #11261. Mark the respective
      tests broken on powerpc64.
      testsuite: mark print022 broken on powerpc64
      Ticket #11262 tracks difference in stdout for print022.
      testsuite: mark recomp015 broken on powerpc64
      testsuite: mark recomp011 broken on powerpc64
      This is tracked as ticket #11323 and #11260.
      testsuite: mark linker tests broken on powerpc64
      Ticket #11259 tracks tests failing because there is no RTS
      linker on powerpc64.
      Test Plan: validate
      Reviewers: erikd, austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1928
      GHC Trac Issues: #11259, #11260, #11261, #11262, #11323