1. 11 May, 2007 1 commit
  2. 10 May, 2007 1 commit
  3. 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
  4. 12 Apr, 2007 3 commits
  5. 08 Mar, 2007 1 commit
  6. 28 Feb, 2007 1 commit
  7. 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
  8. 31 Jan, 2007 1 commit
  9. 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
  10. 11 Dec, 2006 2 commits
  11. 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
  12. 13 Dec, 2006 1 commit
  13. 12 Dec, 2006 1 commit
  14. 04 Dec, 2006 1 commit
  15. 24 Nov, 2006 1 commit
  16. 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
  17. 15 Nov, 2006 1 commit
  18. 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
  19. 07 Oct, 2006 1 commit
  20. 29 Sep, 2006 1 commit
  21. 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
  22. 23 Aug, 2006 2 commits
  23. 07 Jun, 2006 1 commit
  24. 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
  25. 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
  26. 26 Apr, 2006 1 commit
  27. 18 Apr, 2006 1 commit
  28. 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
  29. 28 Mar, 2006 1 commit
  30. 06 Mar, 2006 1 commit
  31. 09 Feb, 2006 1 commit
  32. 28 Feb, 2006 2 commits
    • 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
    • simonpj@microsoft.com's avatar
      badd5d76
  33. 08 Feb, 2006 1 commit
    • Simon Marlow's avatar
      make the smp way RTS-only, normal libraries now work with -smp · beb5737b
      Simon Marlow authored
      We had to bite the bullet here and add an extra word to every thunk,
      to enable running ordinary libraries on SMP.  Otherwise, we would have
      needed to ship an extra set of libraries with GHC 6.6 in addition to
      the two sets we already ship (normal + profiled), and all Cabal
      packages would have to be compiled for SMP too.  We decided it best
      just to take the hit now, making SMP easily accessible to everyone in
      GHC 6.6.
      
      Incedentally, although this increases allocation by around 12% on
      average, the performance hit is around 5%, and much less if your inner
      loop doesn't use any laziness.
      beb5737b