1. 20 Jun, 2018 1 commit
  2. 20 May, 2018 1 commit
    • patrickdoc's avatar
      Add HeapView functionality · ec22f7dd
      patrickdoc authored
      This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC.
      The bits added are the C hooks into the RTS and a basic Haskell wrapper
      to these C hooks. The main reason for these to be added to GHC proper
      is that the code needs to be kept in sync with the closure types
      defined by the RTS. It is expected that the version of HeapView shipped
      with GHC will always work with that version of GHC and that extra
      functionality can be layered on top with a library like ghc-heap-view
      distributed via Hackage.
      
      Test Plan: validate
      
      Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3055
      ec22f7dd
  3. 19 Apr, 2018 2 commits
  4. 09 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Bump template-haskell to 2.14.0.0 · 48f55e76
      Ryan Scott authored
      Summary:
      There has been at least one breaking change to
      `template-haskell` (the removal of `qAddForeignFile`) which is
      causing packages like `th-orphans` and `singletons` to fail to build
      with GHC HEAD. Let's bump `template-haskell`'s major version number
      so that these packages can properly guard against these changes.
      
      While I was in town, I also started a `changelog` section for
      the next major version of `template-haskell`, and copied over
      finishing touches for `template-haskell-2.13.0.0`.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4558
      48f55e76
  5. 25 Sep, 2017 1 commit
  6. 21 Sep, 2017 1 commit
  7. 12 Jul, 2017 1 commit
    • Ben Gamari's avatar
      [iserv] Fixing the word size for RemotePtr and toWordArray · 7ae4a28f
      Ben Gamari authored
      When we load non absolute pathed .so's this usually implies that we
      expect the system to have them in place already, and hence we should not
      need to ship them.  Without the absolute path to the library, we are
      also unable to open and send said library.  Thus we'll do library
      shipping only for libraries with absolute paths.
      
      When dealing with a host and target of different word size (say host
      hast 64bit, target has 32bit), we need to fix the RemotePtr size and the
      toWordArray function, as they are part of the iserv ResolvedBCO binary
      protocol.  This needs to be word size independent.  The choice for
      RemotePtr to 64bit was made to ensure we can store 64bit pointers when
      targeting 64bit. The choice for 32bit word arrays was made wrt.
      encoding/decoding on the potentially slower device.
      
      The efficient serialization code has been graciously provided by
      @bgamari.
      
      Reviewers: bgamari, simonmar, austin, hvr
      
      Reviewed By: bgamari
      
      Subscribers: Ericson2314, rwbarton, thomie, ryantrinkle
      
      Differential Revision: https://phabricator.haskell.org/D3443
      7ae4a28f
  8. 09 Mar, 2017 1 commit
    • bitonic's avatar
      Allow compilation of C/C++/ObjC/ObjC++ files with module from TH · 0fac488c
      bitonic authored
      The main goal is to easily allow the inline-c project (and
      similar projects such as inline-java) to emit C/C++ files to
      be compiled and linked with the current module.
      
      Moreover, `addCStub` is removed, since it's quite fragile. Most
      notably, the C stubs end up in the file generated by
      `CodeOutput.outputForeignStubs`, which is tuned towards
      generating a file for stubs coming from `capi` and Haskell-to-C
      exports.
      
      Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari
      
      Reviewed By: dfeuer, bgamari
      
      Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes
      
      Differential Revision: https://phabricator.haskell.org/D3280
      0fac488c
  9. 02 Feb, 2017 1 commit
    • Ben Gamari's avatar
      Add support for StaticPointers in GHCi · eedb3df0
      Ben Gamari authored
      Here we add support to GHCi for StaticPointers. This process begins by
      adding remote GHCi messages for adding entries to the static pointer
      table. We then collect binders needing SPT entries after linking and
      send the interpreter a message adding entries with the appropriate
      fingerprints.
      
      Test Plan: `make test TEST=StaticPtr`
      
      Reviewers: facundominguez, mboes, simonpj, simonmar, goldfire, austin,
      hvr, erikd
      
      Reviewed By: simonpj, simonmar
      
      Subscribers: RyanGlScott, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2504
      
      GHC Trac Issues: #12356
      eedb3df0
  10. 20 Dec, 2016 1 commit
  11. 19 Dec, 2016 1 commit
  12. 18 Dec, 2016 1 commit
  13. 15 Dec, 2016 1 commit
  14. 12 Nov, 2016 1 commit
  15. 08 Jan, 2016 1 commit
    • Simon Marlow's avatar
      Enable stack traces with ghci -fexternal-interpreter -prof · 6be09e88
      Simon Marlow authored
      Summary:
      The main goal here is enable stack traces in GHCi.  After this change,
      if you start GHCi like this:
      
        ghci -fexternal-interpreter -prof
      
      (which requires packages to be built for profiling, but not GHC
      itself) then the interpreter manages cost-centre stacks during
      execution and can produce a stack trace on request.  Call locations
      are available for all interpreted code, and any compiled code that was
      built with the `-fprof-auto` familiy of flags.
      
      There are a couple of ways to get a stack trace:
      
      * `error`/`undefined` automatically get one attached
      * `Debug.Trace.traceStack` can be used anywhere, and prints the current
        stack
      
      Because the interpreter is running in a separate process, only the
      interpreted code is running in profiled mode and the compiler itself
      isn't slowed down by profiling.
      
      The GHCi debugger still doesn't work with -fexternal-interpreter,
      although this patch gets it a step closer.  Most of the functionality
      of breakpoints is implemented, but the runtime value introspection is
      still not supported.
      
      Along the way I also did some refactoring and added type arguments to
      the various remote pointer types in `GHCi.RemotePtr`, so there's
      better type safety and documentation in the bridge code between GHC
      and ghc-iserv.
      
      Test Plan: validate
      
      Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1747
      
      GHC Trac Issues: #11047, #11100
      6be09e88
  16. 05 Jan, 2016 1 commit
  17. 28 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Synchronise ghci-package version with ghc-package · 01299ca8
      Herbert Valerio Riedel authored
      In order to simplify the task, the version munging logic has
      been radically simplified:
      
      Previously, in cases where the version contained dates as version components,
      the build-system would munge the version of the stage1 ghc package before
      registering the `ghc` package.
      
      However, this hack was already questionable at the time of its introduction
      (c.f. 7b45c46c).
      Simplifying the build-systems by avoiding such hacks may also help the
      shaking-up-ghc effort.
      
      So now we simply munge directly via the `.cabal` files, which gives a simpler
      picture, as now every stage is munged the same. Munging is only active when
      the first patch-level version component is a date. So stable snapshots and release
      candidates are unaffacted (as those have the date in the second patch-level
      version component)
      
      Reviewers: simonmar, bgamari, austin, thomie, ezyang
      
      Reviewed By: bgamari, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1673
      01299ca8
  18. 19 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