1. 16 May, 2007 1 commit
  2. 15 May, 2007 1 commit
    • Simon Marlow's avatar
      GHCi debugger: new flag -fbreak-on-exception · 17f848e1
      Simon Marlow authored
      When -fbreak-on-exception is set, an exception will cause GHCi to
      suspend the current computation and return to the prompt, where the
      history of the current evaluation can be inspected (if we are in
      :trace).  This isn't on by default, because the behaviour could be
      confusing: for example, ^C will cause a breakpoint.  It can be very
      useful for finding the cause of a "head []" or a "fromJust Nothing",
      though.
      17f848e1
  3. 11 May, 2007 1 commit
  4. 10 May, 2007 1 commit
  5. 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
  6. 12 Apr, 2007 3 commits
  7. 08 Mar, 2007 1 commit
  8. 28 Feb, 2007 1 commit
  9. 20 Feb, 2007 1 commit
    • bjpop@csse.unimelb.edu.au's avatar
      Constructor names in info tables · 7d6dffe5
      bjpop@csse.unimelb.edu.au authored
      This patch adds data constructor names into their info tables. 
      This is useful in the ghci debugger. It replaces the old scheme which
      was based on tracking data con names in the linker. 
      7d6dffe5
  10. 31 Jan, 2007 1 commit
  11. 28 Jan, 2007 1 commit
    • Ian Lynagh's avatar
      Fix GHCi on PowerPC OS X · e576ba5d
      Ian Lynagh authored
      David Kirkman and Peter Tanski noticed that a line had been removed during
      a patch merge which meant that oc->image pointed to the wrong place and
      ultimately caused an error from realloc.
      e576ba5d
  12. 11 Dec, 2006 2 commits
  13. 10 Dec, 2006 1 commit
    • mnislaih's avatar
      Retrieving the datacon of an arbitrary closure · ab5b8aa3
      mnislaih authored
      This patch extends the RTS linker and the dynamic linker so that it is possible to find out the datacon of a closure in heap at runtime:
      - The RTS linker now carries a hashtable 'Address->Symbol' for data constructors
      - The Persistent Linker State in the dynamic linker is extended in a similar way.
      
      Finally, these two sources of information are consulted by:
      
      > Linker.recoverDataCon :: a -> TcM Name
      ab5b8aa3
  14. 13 Dec, 2006 1 commit
  15. 12 Dec, 2006 1 commit
  16. 04 Dec, 2006 1 commit
  17. 24 Nov, 2006 1 commit
  18. 21 Nov, 2006 2 commits
    • David Himmelstrup's avatar
      Remove the concept of stableRoots. · 354672b0
      David Himmelstrup authored
      StableRoots opened new possibilities in the world
      of plugins with their ability to link partially
      applied closures against object code.
      Exporting '(fn pluginwideState)' severely reduced
      the complexity of HIDE's plugin system. The previous
      system of global variables was both fragile and hard
      to scale.
      
      Good bye, StableRoots. We sure had some fun.
      354672b0
    • wolfgang.thaller@gmx.net's avatar
      Fix printf$LDBLStub workaround for Darwin · 0329ca6d
      wolfgang.thaller@gmx.net authored
      Apparently, the original fix never really worked due to typos and oversights.
      0329ca6d
  19. 15 Nov, 2006 1 commit
  20. 24 Oct, 2006 1 commit
    • Simon Marlow's avatar
      Split GC.c, and move storage manager into sm/ directory · ab0e778c
      Simon Marlow authored
      In preparation for parallel GC, split up the monolithic GC.c file into
      smaller parts.  Also in this patch (and difficult to separate,
      unfortunatley):
        
        - Don't include Stable.h in Rts.h, instead just include it where
          necessary.
        
        - consistently use STATIC_INLINE in source files, and INLINE_HEADER
          in header files.  STATIC_INLINE is now turned off when DEBUG is on,
          to make debugging easier.
        
        - The GC no longer takes the get_roots function as an argument.
          We weren't making use of this generalisation.
      ab0e778c
  21. 07 Oct, 2006 1 commit
  22. 29 Sep, 2006 1 commit
  23. 21 Sep, 2006 1 commit
    • Don Stewart's avatar
      Use --export-dynamic to ensure ghci works on newer openbsds · 069495a3
      Don Stewart authored
      Changes to the RTLD_DEFAULT semantics broke the trick we used to ensure
      libc symbols were available to the ghci linker, in OpenBSD 4.0. We can
      fix this by linking the ghc binary itself with --export-dynamic on this
      system, removing the need for any magic Linker.c games.
      
      GHCi now works on OpenBSD 4.0
      
      Contributed by Eric Mertens <emertens at gmail.com>
      069495a3
  24. 23 Aug, 2006 2 commits
  25. 07 Jun, 2006 1 commit
  26. 30 May, 2006 2 commits
    • simonmar@microsoft.com's avatar
      Win32: add _imp__tzname · 4285fd96
      simonmar@microsoft.com authored
      4285fd96
    • Simon Marlow's avatar
      replace stgMallocBytesRWX() with our own allocator · e3c55aeb
      Simon Marlow authored
      See bug #738
      
      Allocating executable memory is getting more difficult these days.  In
      particular, the default SELinux policy on Fedora Core 5 disallows
      making the heap (i.e. malloc()'d memory) executable, although it does
      apparently allow mmap()'ing anonymous executable memory by default.
      
      Previously, stgMallocBytesRWX() used malloc() underneath, and then
      tried to make the page holding the memory executable.  This was rather
      hacky and fails with Fedora Core 5.  
      
      This patch adds a mini-allocator for executable memory, based on the
      block allocator.  We grab page-sized blocks and make them executable,
      then allocate small objects from the page.  There's a simple free
      function, that will free whole pages back to the system when they are
      empty.
      e3c55aeb
  27. 16 May, 2006 1 commit
    • duncan.coutts@worc.ox.ac.uk's avatar
      Let GHCi work with with Sparc32+/V8+ .o files · 82807c21
      duncan.coutts@worc.ox.ac.uk authored
      Currently the GHCi linker looks exclusively for V7 ABI .o files.
      
      You can generate V8+ ABI .o files using flags to gcc such as:
       -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
      
      Note that this allows gcc to generate hardware integer division and
      hardware floating point instructions rather than using software emulation.
      All recent sparc hardware is V8+ or later. Perhaps we should check for the
      cpu generation in configure and use the later ABI if possible.
      
      Tested briefly on a SunBlade 100 (TI UltraSparc IIe) sparc-unknown-linux
      82807c21
  28. 26 Apr, 2006 1 commit
  29. 18 Apr, 2006 1 commit
  30. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  31. 28 Mar, 2006 1 commit
  32. 06 Mar, 2006 1 commit
  33. 09 Feb, 2006 1 commit
  34. 28 Feb, 2006 1 commit
    • Simon Marlow's avatar
      pass arguments to unknown function calls in registers · 04db0e9f
      Simon Marlow authored
      We now have more stg_ap entry points: stg_ap_*_fast, which take
      arguments in registers according to the platform calling convention.
      This is faster if the function being called is evaluated and has the
      right arity, which is the common case (see the eval/apply paper for
      measurements).  
      
      We still need the stg_ap_*_info entry points for stack-based
      application, such as an overflows when a function is applied to too
      many argumnets.  The stg_ap_*_fast functions actually just check for
      an evaluated function, and if they don't find one, push the args on
      the stack and invoke stg_ap_*_info.  (this might be slightly slower in
      some cases, but not the common case).
      04db0e9f