1. 02 Dec, 2016 1 commit
    • Alexander Vershilov's avatar
      Install toplevel handler inside fork. · fb0f4cf6
      Alexander Vershilov authored
      When rts is forked it doesn't update toplevel handler, so UserInterrupt
      exception is sent to Thread1 that doesn't exist in forked process.
      
      We install toplevel handler when fork so signal will be delivered to the
      new main thread.
      
      Fixes #12903
      
      Reviewers: simonmar, austin, erikd, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2770
      
      GHC Trac Issues: #12903
      
      (cherry picked from commit 895a131f)
      fb0f4cf6
  2. 11 Nov, 2016 1 commit
  3. 07 Nov, 2016 1 commit
    • Tamar Christina's avatar
      Align GHCi's library search order more closely with LDs · 95b6affc
      Tamar Christina authored
      Summary:
      Given a static library and an import library in the same folder. e.g.
      
      ```
      libfoo.a
      libfoo.dll.a
      ```
      
      running `ghci -lfoo` we should prefer the import library `libfoo.dll.a`
      over `libfoo.a` because we prefer having to just load the DLL.
      And not having to do any linking.
      
      This also more closely emulated the behaviour of LD, which has a search order of
      
      ```
      libxxx.dll.a
      xxx.dll.a
      libxxx.a
      cygxxx.dll (*)
      libxxx.dll
      xxx.dll
      ```
      
      Test Plan: ./validate
      
      Reviewers: RyanGlScott, austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: RyanGlScott
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2651
      
      GHC Trac Issues: #12771
      
      (cherry picked from commit 795be0ea)
      95b6affc
  4. 05 Sep, 2016 1 commit
    • Tamar Christina's avatar
      Added support for deprecated POSIX functions on Windows. · 714779c7
      Tamar Christina authored
      Summary:
      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
      
      https://msdn.microsoft.com/en-us/library/ms235384.aspx.
      
      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:
      ./validate
      and
      
      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
      
      (cherry picked from commit e5ecb201)
      714779c7
  5. 31 Aug, 2016 1 commit
  6. 30 Aug, 2016 1 commit
  7. 26 Aug, 2016 1 commit
    • Tamar Christina's avatar
      Fix incorrect calculated relocations on Windows x86_64 · 38497a23
      Tamar Christina authored
      Summary:
      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));
      ```
      
      Where
      ```
      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
      
      (cherry picked from commit b40e1b4c)
      38497a23
  8. 25 Jul, 2016 1 commit
    • mlen's avatar
      Fix histograms for ticky code · f0eb4f7a
      mlen authored
      This patch fixes Cmm generation required to produce histograms when
      compiling with -ticky flag, strips dead code from rts/Ticky.c and
      reworks it to use a shared constant in both C and Haskell code.
      
      Fixes #8308.
      
      Test Plan: T8308
      
      Reviewers: jstolarek, simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: mpickering, simonpj, bgamari, mlen, thomie, jstolarek
      
      Differential Revision: https://phabricator.haskell.org/D931
      
      GHC Trac Issues: #8308
      
      (cherry picked from commit f0f0ac85)
      f0eb4f7a
  9. 10 Apr, 2016 1 commit
    • Tamar Christina's avatar
      Change runtime linker to perform lazy loading of symbols/sections · 068d9273
      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 inst...
      068d9273
  10. 05 Apr, 2016 1 commit
  11. 24 Mar, 2016 1 commit
  12. 27 Feb, 2016 2 commits
  13. 27 Jan, 2016 1 commit
    • thomie's avatar
      Fix segmentation fault when .prof file not writeable · 8efe964a
      thomie authored
      There are two ways to do retainer profiling. Quoting from the user's guide:
        1. `+RTS -hr` "Breaks down the graph by retainer set"
        2. `+RTS -hr<cc> -h<x>`, where `-h<x>` is one of normal heap profiling
           break-down options (e.g. `-hc`), and `-hr<cc> means "Restrict the
           profile to closures with retainer sets containing cost-centre
           stacks with one of the specified cost centres at the top."
      
      Retainer profiling writes to a .hp file, like the other heap profiling
      options, but also to a .prof file. Therefore, when the .prof file is not
      writeable for whatever reason, retainer profiling should be turned off
      completely.
      
      This worked ok when running the program with `+RTS -hr` (option 1), but a
      segfault would occur when using `+RTS -hr<cc> -h<x>`, with `x!=r` (option 2).
      
      This commit fixes that.
      
      Reviewed by: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1849
      
      GHC Trac Issues: #11489
      
      (cherry picked from commit 6d2bdfd8)
      8efe964a
  14. 29 Dec, 2015 1 commit
    • Rik Steenkamp's avatar
      Modify getFullArgs to include program name · b093e631
      Rik Steenkamp authored
      Fixes an inconsistency of `getFullArgs` across operating systems. On
      non-Windows systems the returning list did not include the program name
      as the first element, while on Windows systems it did.
      
      As `System.Environment` depends on this behaviour of `getFullArgs` under
      Windows, this is now the behaviour across all operating systems.
      Computation `getFullArgs` is now like the "raw" version of `getArgs`,
      similar to `argv` in other languages.
      
      This patch also fixes T10728 under Windows.
      
      Reviewers: austin, hvr, erikd, #ghc_windows_task_force, Phyx, bgamari
      
      Reviewed By: #ghc_windows_task_force, Phyx, bgamari
      
      Subscribers: Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1713
      b093e631
  15. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
  16. 23 Dec, 2015 1 commit
    • MarcelineVQ's avatar
      Modify Nmax to maxN Trac #10728 · 7ed0da6c
      MarcelineVQ authored
      Added test and changed -Nmax to -maxN, -n was taken
      
      Noticed strange -m behavoir and fixed -m from quietly
      ignoring being passed invalid opts, e.g. "-msasd"
      
      Reviewers: simonmar, hvr, austin, thomie, bgamari
      
      Reviewed By: hvr, thomie, bgamari
      
      Subscribers: bgamari, hvr, thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D1677
      
      GHC Trac Issues: #10728
      7ed0da6c
  17. 22 Dec, 2015 1 commit
    • Ryan Scott's avatar
      Rework Template Haskell's handling of strictness · f975b0b1
      Ryan Scott authored
      Currently, Template Haskell's treatment of strictness is not enough to
      cover all possible combinations of unpackedness and strictness. In
      addition, it isn't equipped to deal with new features (such as
      `-XStrictData`) which can change a datatype's fields' strictness during
      compilation.
      
      To address this, I replaced TH's `Strict` datatype with
      `SourceUnpackedness` and `SourceStrictness` (which give the programmer a
      more complete toolkit to configure a datatype field's strictness than
      just `IsStrict`, `IsLazy`, and `Unpack`). I also added the ability to
      reify a constructor fields' strictness post-compilation through the
      `reifyConStrictness` function.
      
      Fixes #10697.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, goldfire, bgamari, austin
      
      Reviewed By: goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1603
      
      GHC Trac Issues: #10697
      f975b0b1
  18. 21 Dec, 2015 1 commit
  19. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  20. 14 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Use Cxt for deriving clauses in TH (#10819) · 04ab55d9
      Ben Gamari authored
      Summary:
      Deriving clauses in the TH representations of data, newtype, data
      instance, and newtype instance declarations previously were just [Name],
      which didn't allow for more complex derived classes, eg. multi-parameter
      typeclasses.
      
      This switches out [Name] for Cxt, representing the derived classes as
      types instead of names.
      
      Test Plan: validate
      
      Reviewers: goldfire, spinda, austin
      
      Reviewed By: goldfire, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1202
      
      GHC Trac Issues: #10819
      04ab55d9
  21. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  22. 29 Oct, 2015 1 commit
  23. 26 Oct, 2015 1 commit
  24. 15 Oct, 2015 1 commit
    • Simon Marlow's avatar
      ELF/x86_64: map object file sections separately into the low 2GB · 04e83666
      Simon Marlow authored
      On 64-bit ELF we need to link object files into the low 2GB due to the
      small memory model.  Previously we would map the entire object file
      using MAP_32BIT, but the object file can consist of 75% or more
      symbols, which only need to be present during linking, so this is
      wasteful.  In our particular application, we're already running out of
      space here.
      
      This patch changes the way we load object files on ELF platforms so
      that the object is first mapped above the 2GB boundary, parsed, and
      then the important sections are re-mapped into the low 2GB area.
      
      Test Plan:
      validate
      (also needs testing on OS X & Windows, preferably 32 & 64 bit)
      
      Reviewers: Phyx, trommler, bgamari, austin
      
      Subscribers: hsyl20, thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D975
      04e83666
  25. 03 Oct, 2015 1 commit
    • Tamar Christina's avatar
      Make Windows linker more robust to unknown sections · 620fc6f9
      Tamar Christina authored
      The Windows Linker has 3 main parts that this patch changes.
      
      1) Identification and classification of sections
      2) Adding of symbols to the symbols tables
      3) Reallocation of sections
      
      1.
      Previously section identification used to be done on a whitelisted
      basis. It was also exclusively being done based on the names of the
      sections. This meant that there was a bit of a cat and mouse game
      between `GCC` and `GHC`. Every time `GCC` added new sections there was a
      good chance `GHC` would break. Luckily this hasn't happened much in the
      past because the `GCC` versions `GHC` used were largely unchanged.
      
      The new code instead treats all new section as `CODE` or `DATA`
      sections, and changes the classifications based on the `Characteristics`
      flag in the PE header. By doing so we no longer have the fragility of
      changing section names. The one exception to this is the `.ctors`
      section, which has no differentiating flag in the PE header, but we know
      we need to treat it as initialization data.
      
      The check to see if the sections are aligned by `4` has been removed.
      The reason is that debug sections often time are `1 aligned` but do have
      relocation symbols. In order to support relocations of `.debug` sections
      this check needs to be gone. Crucially this assumption doesn't seem to
      be in the rest of the code. We only check if there are at least 4 bytes
      to realign further down the road.
      
      2.
      The second loop is iterating of all the symbols in the file and trying
      to add them to the symbols table. Because the classification of the
      sections we did previously are (currently) not available in this phase
      we still have to exclude the sections by hand. If they don't we will
      load in symbols from sections we've explicitly ignored the in # 1. This
      whole part should rewritten to avoid this. But didn't want to do it in
      this commit.
      
      3.
      Finally the sections are relocated. But for some reason the PE files
      contain a Linux relocation constant in them `0x0011` This constant as
      far as I can tell does not come from GHC (or I couldn't find where it's
      being set). I believe this is probably a bug in GAS. But because the
      constant is in the output we have to handle it. I am thus mapping it to
      the constant I think it should be `0x0003`.
      
      Finally, static linking *should* work, but won't. At least not if you
      want to statically link `libgcc` with exceptions support. Doing so would
      require you to link `libgcc` and `libstd++` but also `libmingwex`. The
      problem is that `libmingwex` also defines a lot of symbols that the RTS
      automatically injects into the symbol table. Presumably because they're
      symbols that it needs. like `coshf`. The these symbols are not in a
      section that is declared with weak symbols support. So if we ever want
      to get this working, we should either a) Ask mingw to declare the
      section as such, or b) treat all a imported symbols as being weak.
      Though this doesn't seem like it's a good idea..
      
      Test Plan:
      Running ./validate for both x86 and x86_64
      
      Also running the specific test case for #10672
      
      make TESTS="T10672_x86 T10672_x64"
      
      Reviewed By: ezyang, thomie, austin
      
      Differential Revision: https://phabricator.haskell.org/D1244
      
      GHC Trac Issues: #9907, #10672, #10563
      620fc6f9
  26. 24 Sep, 2015 1 commit
  27. 18 Aug, 2015 1 commit
    • Tamar Christina's avatar
      Fix rdynamic flag and test on Windows · b17ec567
      Tamar Christina authored
      The rdynamic tests and feature are marked broken on windows.
      This is because the flag used doesn't exist and the symbol lookup
      in the test did not account for platform differences in name mangling.
      
      This commit fixes the flag and tests for rdynamic on windows.
      
      Test Plan:
      make TEST="rdynamic"
      
      on both x86 and x86_64
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1149
      
      GHC Trac Issues: #9381
      b17ec567
  28. 12 Aug, 2015 1 commit
    • Tamar Christina's avatar
      Upgrade GCC to 5.2.0 for Windows x86 and x86_64 · 7b211b4e
      Tamar Christina authored
      This patch does a few things
      
      - Moved GHC x86 to MinGW-w64 (Using Awson's patch)
      - Moves Both GHCs to MSYS2 toolchains
      - Completely removes the dependencies on the git tarball repo
        - Downloads only the required tarball for the architecture for
          which we are building
        - Downloads the perl tarball is missing as well
        - Fixed a few bugs in the linker to fix tests on Windows
      
      The links currently point to repo.msys2.org and GitHub, it might be
      more desirable to mirror them on
      http://downloads.haskell.org/~ghc/mingw/ as with the previous patch
      attempt.
      
      For more details on what the MSYS2 packages I include see #10726
      (Awson's comment). but it should contain all we need
      and no python or fortran, which makes the uncompressed tar a 1-2
      hundreds mb smaller.
      
      The `GCC 5.2.0` in the package supports `libgcc` as a shared library,
      this is a problem since
      when compiling with -shared the produced dll now has a dependency on
      `libgcc_s_sjlj-1.dll`.
      To solve this the flag `-static-libgcc` is now being used for all GCC
      calls on windows.
      
      Test Plan:
      ./validate was ran both on x86 and x86_64 windows and compared against
      the baseline.
      
      A few test were failing due to Ld no longer being noisy. These were
      updated.
      
      The changes to the configure script *should* be validated by the build
      bots for the other platforms before landing
      
      Reviewers: simonmar, awson, bgamari, austin, thomie
      
      Reviewed By: thomie
      
      Subscribers: #ghc_windows_task_force, thomie, awson
      
      Differential Revision: https://phabricator.haskell.org/D1123
      
      GHC Trac Issues: #10726, #9014, #9218, #10435
      7b211b4e
  29. 31 Jul, 2015 1 commit
    • Simon Marlow's avatar
      Fix #7919 (again) · 7cf87dfb
      Simon Marlow authored
      Summary:
      The fix is a bit clunky, and is perhaps not the best fix, but I'm not
      sure how much work it would be to fix it the other way (see comments
      for more info).
      
      Test Plan: T7919 doesn't crash
      
      Reviewers: austin, rwbarton, ezyang, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1113
      
      GHC Trac Issues: #7919
      7cf87dfb
  30. 22 Jul, 2015 1 commit
    • gcampax's avatar
      Two step allocator for 64-bit systems · 0d1a8d09
      gcampax authored
      Summary:
      The current OS memory allocator conflates the concepts of allocating
      address space and allocating memory, which makes the HEAP_ALLOCED()
      implementation excessively complicated (as the only thing it cares
      about is address space layout) and slow. Instead, what we want
      is to allocate a single insanely large contiguous block of address
      space (to make HEAP_ALLOCED() checks fast), and then commit subportions
      of that in 1MB blocks as we did before.
      This is currently behind a flag, USE_LARGE_ADDRESS_SPACE, that is only enabled for
      certain OSes.
      
      Test Plan: validate
      
      Reviewers: simonmar, ezyang, austin
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D524
      
      GHC Trac Issues: #9706
      0d1a8d09
  31. 18 Jul, 2015 1 commit
  32. 17 Jul, 2015 1 commit
    • thomie's avatar
      Testsuite: small test cleanups · ac0feece
      thomie authored
      * don't print anything to stdout
      * add missing Makefile
      * also ignore mk/ghcconfig*.mk when using installed compiler
      * prevent warning: -rtsopts and -with-rtsopts have no effect with -shared
      ac0feece
  33. 07 Jul, 2015 1 commit
    • Sergei Trofimovich's avatar
      fix EBADF unqueueing in select backend (Trac #10590) · 5857e0af
      Sergei Trofimovich authored
      
      
      Alexander found a interesting case:
      1. We have a queue of two waiters in a blocked_queue
      2. first file descriptor changes state to RUNNABLE,
         second changes to INVALID
      3. awaitEvent function dequeued RUNNABLE thread to a
         run queue and attempted to dequeue INVALID descriptor
         to a run queue.
      
      Unqueueing INVALID fails thusly:
              #3  0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found")
                                     at rts/RtsMessages.c:42
              #4  0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249
              #5  0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719
              #6  0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67
              #7  0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75
              #8  0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415
      
      The problem here is a throwToSingleThreaded function that tries
      to unqueue a TSO from blocked_queue, but awaitEvent function
      leaves blocked_queue in a inconsistent state while traverses
      over blocked_queue:
      
            case RTS_FD_IS_READY:
                IF_DEBUG(scheduler,
                    debugBelch("Waking up blocked thread %lu\n",
                               (unsigned long)tso->id));
                tso->why_blocked = NotBlocked;
                tso->_link = END_TSO_QUEUE;              // Here we break the queue head
                pushOnRunQueue(&MainCapability,tso);
                break;
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Test Plan: tested on a sample from T10590
      
      Reviewers: austin, bgamari, simonmar
      
      Reviewed By: bgamari, simonmar
      
      Subscribers: qnikst, thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1024
      
      GHC Trac Issues: #10590, #4934
      5857e0af
  34. 05 Jul, 2015 1 commit
  35. 03 Jul, 2015 1 commit
    • Peter Trommler's avatar
      Implement PowerPC 64-bit native code backend for Linux · d3c1dda6
      Peter Trommler authored
      Extend the PowerPC 32-bit native code generator for "64-bit
      PowerPC ELF Application Binary Interface Supplement 1.9" by
      Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
      OpenPOWER ABI for Linux Supplement" by IBM.
      The latter ABI is mainly used on POWER7/7+ and POWER8
      Linux systems running in little-endian mode. The code generator
      supports both static and dynamic linking. PowerPC 64-bit
      code for ELF ABI 1.9 and 2 is mostly position independent
      anyway, and thus so is all the code emitted by the code
      generator. In other words, -fPIC does not make a difference.
      
      rts/stg/SMP.h support is implemented.
      
      Following the spirit of the introductory comment in
      PPC/CodeGen.hs, the rest of the code is a straightforward
      extension of the 32-bit implementation.
      
      Limitations:
      * Code is generated only in the medium code model, which
        is also gcc's default
      * Local symbols are not accessed directly, which seems to
        also be the case for 32-bit
      * LLVM does not work, but this does not work on 32-bit either
      * Must use the system runtime linker in GHCi, because the
        GHC linker for "static" object files (rts/Linker.c) for
        PPC 64-bit is not implemented. The system runtime
        (dynamic) linker works.
      * The handling of the system stack (register 1) is not ELF-
        compliant so stack traces break. Instead of allocating a new
        stack frame, spill code should use the "official" spill area
        in the current stack frame and deallocation code should restore
        the back chain
      * DWARF support is missing
      
      Fixes #9863
      
      Test Plan: validate (on powerpc, too)
      
      Reviewers: simonmar, trofi, erikd, austin
      
      Reviewed By: trofi
      
      Subscribers: bgamari, arnons1, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D629
      
      GHC Trac Issues: #9863
      d3c1dda6
  36. 11 Jun, 2015 1 commit
  37. 04 Jun, 2015 1 commit
    • thomie's avatar
      Testsuite: don't show compile/link info for some tests · 0686d76f
      thomie authored
      This info is not needed in the testlogs, and was actually making these
      tests fail on my machine because of some bug with the timeout program:
      ...
      [1 of 1] Compiling Main ( OutOfHeap.hs, tmp_T9579_outofheap_rtssome/Main.o )
      Linking T9579_outofheap_rtsnone ...
      ...
      0686d76f
  38. 31 May, 2015 1 commit
  39. 26 May, 2015 1 commit