1. 16 Nov, 2010 1 commit
  2. 21 Oct, 2010 1 commit
  3. 19 Sep, 2010 1 commit
    • Edward Z. Yang's avatar
      Interruptible FFI calls with pthread_kill and CancelSynchronousIO. v4 · 83d563cb
      Edward Z. Yang authored
      This is patch that adds support for interruptible FFI calls in the form
      of a new foreign import keyword 'interruptible', which can be used
      instead of 'safe' or 'unsafe'.  Interruptible FFI calls act like safe
      FFI calls, except that the worker thread they run on may be interrupted.
      
      Internally, it replaces BlockedOnCCall_NoUnblockEx with
      BlockedOnCCall_Interruptible, and changes the behavior of the RTS
      to not modify the TSO_ flags on the event of an FFI call from
      a thread that was interruptible.  It also modifies the bytecode
      format for foreign call, adding an extra Word16 to indicate
      interruptibility.
      
      The semantics of interruption vary from platform to platform, but the
      intent is that any blocking system calls are aborted with an error code.
      This is most useful for making function calls to system library
      functions that support interrupting.  There is no support for pre-Vista
      Windows.
      
      There is a partner testsuite patch which adds several tests for this
      functionality.
      83d563cb
  4. 23 Sep, 2010 1 commit
  5. 14 Sep, 2010 1 commit
    • Ian Lynagh's avatar
      Remove (most of) the FiniteMap wrapper · e95ee1f7
      Ian Lynagh authored
      We still have
          insertList, insertListWith, deleteList
      which aren't in Data.Map, and
          foldRightWithKey
      which works around the fold(r)WithKey addition and deprecation.
      e95ee1f7
  6. 13 Sep, 2010 1 commit
  7. 04 Jan, 2010 1 commit
  8. 02 Jan, 2010 1 commit
  9. 18 Sep, 2009 1 commit
  10. 03 Aug, 2009 1 commit
  11. 01 Aug, 2009 1 commit
  12. 30 Jul, 2009 1 commit
  13. 29 Jul, 2009 1 commit
  14. 06 Jul, 2009 1 commit
  15. 20 Apr, 2009 1 commit
    • Simon Marlow's avatar
      FIX #2845: Allow breakpoints on expressions with unlifted type · 709c9ce0
      Simon Marlow authored
      It turns out we can easily support breakpoints on expressions with
      unlifted types, by translating 
      
        case tick# of _ -> e
      
      into
      
        let f = \s . case tick# of _ -> e 
        in  f realWorld#
      
      instead of just a plain let-binding.  This is the same trick that GHC
      uses for abstracting join points of unlifted type.
      
      In #2845, GHC has eta-expanded the tick expression, changing the
      result type from IO a to (# State#, a #), which was the reason the
      tick was suddenly being ignored.  By supporting ticks on unlifted
      expressions we can make it work again, although some confusion might
      arise because _result will no longer be available (it now has
      unboxed-tuple type, so we can't bind it in the environment).  The
      underlying problem here is that GHC does transformations like
      eta-expanding the tick expressions, and there's nothing we can do to
      prevent that.
      709c9ce0
  16. 06 Feb, 2009 1 commit
    • Ian Lynagh's avatar
      When generating C, don't pretend functions are data · 497302c4
      Ian Lynagh authored
      We used to generated things like:
          extern StgWordArray (newCAF) __attribute__((aligned (8)));
          ((void (*)(void *))(W_)&newCAF)((void *)R1.w);
      (which is to say, pretend that newCAF is some data, then cast it to a
      function and call it).
      This goes wrong on at least IA64, where:
          A function pointer on the ia64 does not point to the first byte of
          code. Intsead, it points to a structure that describes the function.
          The first quadword in the structure is the address of the first byte
          of code
      so we end up dereferencing function pointers one time too many, and
      segfaulting.
      497302c4
  17. 30 Dec, 2008 1 commit
    • simonpj@microsoft.com's avatar
      Tidy up treatment of big lambda (fixes Trac #2898) · 85f8276b
      simonpj@microsoft.com authored
      There was a leftover big lambda in the CorePrep'd code, which confused
      the bytecode generator.  Actually big lambdas are harmless.  This patch
      refactors ByteCodeGen so that it systemantically used 'bcView' to eliminate
      junk.  I did a little clean up in CorePrep too.
      
      See comments in Trac #2898.
      85f8276b
  18. 11 Dec, 2008 1 commit
  19. 09 Oct, 2008 1 commit
  20. 30 Jul, 2008 1 commit
  21. 15 May, 2008 1 commit
  22. 14 May, 2008 1 commit
  23. 04 May, 2008 1 commit
  24. 12 Apr, 2008 1 commit
  25. 08 Apr, 2008 1 commit
    • Simon Marlow's avatar
      Import libffi-3.0.4, and use it to provide FFI support in GHCi · e0fcf61d
      Simon Marlow authored
      This replaces the hand-rolled architecture-specific FFI support in
      GHCi with the standard libffi as used in GCJ, Python and other
      projects.  I've bundled the complete libffi-3.0.4 tarball in the
      source tree in the same way as we do for GMP, the difference being
      that we always build and install our own libffi regardless of whether
      there's one on the system (it's small, and we don't want
      dependency/versioning headaches).
      
      In particular this means that unregisterised builds will now have a
      fully working GHCi including FFI out of the box, provided libffi
      supports the platform.
      
      There is also code in the RTS to use libffi in place of
      rts/Adjustor.c, but it is currently not enabled if we already have
      support in Adjustor.c for the current platform.  We need to assess the
      performance impact before using libffi here too (in GHCi we don't care
      too much about performance).
      e0fcf61d
  26. 04 Feb, 2008 1 commit
    • Simon Marlow's avatar
      Support for using libffi to implement FFI calls in GHCi (#631) · 937eb1f1
      Simon Marlow authored
      This means that an unregisterised build on a platform not directly
      supported by GHC can now have full FFI support using libffi.
      
      Also in this commit:
      
       - use PrimRep rather than CgRep to describe FFI args in the byte
         code generator.  No functional changes, but PrimRep is more correct.
      
       - change TyCon.sizeofPrimRep to primRepSizeW, which is more useful
      937eb1f1
  27. 10 Oct, 2007 1 commit
    • Simon Marlow's avatar
      GHCi: use non-updatable thunks for breakpoints · 27779403
      Simon Marlow authored
      The extra safe points introduced for breakpoints were previously
      compiled as normal updatable thunks, but they are guaranteed
      single-entry, so we can use non-updatable thunks here.  This restores
      the tail-call property where it was lost in some cases (although stack
      squeezing probably often recovered it), and should improve
      performance.
      27779403
  28. 11 Sep, 2007 1 commit
    • Simon Marlow's avatar
      FIX #1466 (partly), which was causing concprog001(ghci) to fail · 066f1028
      Simon Marlow authored
      An AP_STACK now ensures that there is at least AP_STACK_SPLIM words of
      stack headroom available after unpacking the payload.  Continuations
      that require more than AP_STACK_SPLIM words of stack must do their own
      stack checks instead of aggregating their stack usage into the parent
      frame.  I have made this change for the interpreter, but not for
      compiled code yet - we should do this in the glorious rewrite of the
      code generator.
      066f1028
  29. 04 Sep, 2007 1 commit
  30. 03 Sep, 2007 1 commit
  31. 01 Sep, 2007 1 commit
  32. 18 May, 2007 1 commit
  33. 27 Apr, 2007 1 commit
  34. 25 Apr, 2007 1 commit
  35. 18 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Various cleanups and improvements to the breakpoint support · 38e7ac3f
      Simon Marlow authored
        - move parts of the debugger implementation below the GHC API where
          they belong.  There is still more in Debugger that violates the
          layering, hopefully I'll get to that later.
      
        - instead of returning an IO action from runStmt for resuming,
          return a ResumeHandle that is passed to GHC.resume.
      
        - breakpoints now return [Name] which is displayed in the same
          way as when a binding statement is executed.
      
        - :load, :add, :reload now clear the active breakpoints and context
      
        - :break gives a sensible error when used on a non-interpreted module
      
        - export breakpoint-related types from GHC
      
        - remove a bunch of layer-violating imports from InteractiveUI
      
        - remove some more vestiges of the old breakpoint code (topLevel in
          the GHCi state).
      
        - remove TickTree and use a simple array instead, cached per module
      38e7ac3f
  36. 17 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Re-working of the breakpoint support · cdce6477
      Simon Marlow authored
      This is the result of Bernie Pope's internship work at MSR Cambridge,
      with some subsequent improvements by me.  The main plan was to
      
       (a) Reduce the overhead for breakpoints, so we could enable 
           the feature by default without incurrent a significant penalty
       (b) Scatter more breakpoint sites throughout the code
      
      Currently we can set a breakpoint on almost any subexpression, and the
      overhead is around 1.5x slower than normal GHCi.  I hope to be able to
      get this down further and/or allow breakpoints to be turned off.
      
      This patch also fixes up :print following the recent changes to
      constructor info tables.  (most of the :print tests now pass)
      
      We now support single-stepping, which just enables all breakpoints.
      
        :step <expr>     executes <expr> with single-stepping turned on
        :step            single-steps from the current breakpoint
      
      The mechanism is quite different to the previous implementation.  We
      share code with the HPC (haskell program coverage) implementation now.
      The coverage pass annotates source code with "tick" locations which
      are tracked by the coverage tool.  In GHCi, each "tick" becomes a
      potential breakpoint location.
      
      Previously breakpoints were compiled into code that magically invoked
      a nested instance of GHCi.  Now, a breakpoint causes the current
      thread to block and control is returned to GHCi.
      
      See the wiki page for more details and the current ToDo list:
      
        http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
      cdce6477
  37. 04 Apr, 2007 1 commit
  38. 08 Mar, 2007 1 commit
  39. 22 Dec, 2006 1 commit
  40. 21 Dec, 2006 1 commit