1. 13 Nov, 2008 1 commit
  2. 12 Nov, 2008 1 commit
  3. 06 Nov, 2008 1 commit
  4. 13 Oct, 2008 1 commit
  5. 10 Oct, 2008 1 commit
  6. 16 Sep, 2008 1 commit
  7. 15 Sep, 2008 1 commit
    • Simon Marlow's avatar
      Stop using mremap() to allocate space for trampolines · bf7e78fa
      Simon Marlow authored
      This was causing problems because sometimes mremap() moved the memory
      we had allocated from the low 2Gb to above the 2Gb boundary, causing
      some linkages to fail.  There's no MAP_32BIT flag to mremap().
      So now we just use mmap(MAP_ANON|MAP_32BIT) to allocated space for the
      trampolines.  People without MAP_32BIT (eg. *BSD) will still have to
      do something else here, such as allocating memory from a fixed
      address; so I've made it slightly easier for those guys, but there's
      still work to do (#2063).
      One solution (that Simon PJ is advocating) is to turn on -fPIC by
      default on x86-64.  This is a good solution as it removes the need for
      MAP_32BIT, but doesn't work with -fvia-C, so probably this is for
  8. 08 Sep, 2008 1 commit
  9. 03 Sep, 2008 1 commit
    • Simon Marlow's avatar
      Windows: print an error message in addDLL · b9110541
      Simon Marlow authored
      Also, look for libXXX.dll in addition to XXX.dll (see #1883, this
      isn't really a proper fix, but it'll help in some cases).
      And I tidied up the error message for a DLL load failure, though it's
      still a bit of a mess because addDLL is supposed to return a (static)
      string with the error message, but this isn't possible on Windows.
  10. 04 Aug, 2008 3 commits
  11. 30 Jul, 2008 2 commits
  12. 24 Jul, 2008 2 commits
  13. 14 Jul, 2008 1 commit
  14. 10 Jul, 2008 1 commit
  15. 09 Jul, 2008 2 commits
    • Simon Marlow's avatar
    • Simon Marlow's avatar
      FIX part of #2301, and #1619 · addff19a
      Simon Marlow authored
      2301: Control-C now causes the new exception (AsyncException
      UserInterrupt) to be raised in the main thread.  The signal handler
      is set up by GHC.TopHandler.runMainIO, and can be overriden in the
      usual way by installing a new signal handler.  The advantage is that
      now all programs will get a chance to clean up on ^C.
      When UserInterrupt is caught by the topmost handler, we now exit the
      program via kill(getpid(),SIGINT), which tells the parent process that
      we exited as a result of ^C, so the parent can take appropriate action
      (it might want to exit too, for example).
      One subtlety is that we have to use a weak reference to the ThreadId
      for the main thread, so that the signal handler doesn't prevent the
      main thread from being subject to deadlock detection.
      1619: we now ignore SIGPIPE by default.  Although POSIX says that a
      SIGPIPE should terminate the process by default, I wonder if this
      decision was made because many C applications failed to check the exit
      code from write().  In Haskell a failed write due to a closed pipe
      will generate an exception anyway, so the main difference is that we
      now get a useful error message instead of silent program termination.
      See #1619 for more discussion.
  16. 14 Jun, 2008 1 commit
  17. 28 May, 2008 1 commit
  18. 17 Apr, 2008 1 commit
  19. 09 Apr, 2008 1 commit
  20. 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).
  21. 02 Apr, 2008 1 commit
    • Simon Marlow's avatar
      Do not #include external header files when compiling via C · c245355e
      Simon Marlow authored
      This has several advantages:
       - -fvia-C is consistent with -fasm with respect to FFI declarations:
         both bind to the ABI, not the API.
       - foreign calls can now be inlined freely across module boundaries, since
         a header file is not required when compiling the call.
       - bootstrapping via C will be more reliable, because this difference
         in behavour between the two backends has been removed.
      There is one disadvantage:
       - we get no checking by the C compiler that the FFI declaration
         is correct.
      So now, the c-includes field in a .cabal file is always ignored by
      GHC, as are header files specified in an FFI declaration.  This was
      previously the case only for -fasm compilations, now it is also the
      case for -fvia-C too.
  22. 01 Jan, 2008 1 commit
  23. 20 Nov, 2007 1 commit
    • Simon Marlow's avatar
      Move file locking into the RTS, fixing #629, #1109 · 1d026619
      Simon Marlow authored
      File locking (of the Haskell 98 variety) was previously done using a
      static table with linear search, which had two problems: the array had
      a fixed size and was sometimes too small (#1109), and performance of
      lockFile/unlockFile was suboptimal due to the linear search.
      Also the algorithm failed to count readers as required by Haskell 98
      Now it's done using a hash table (provided by the RTS).  Furthermore I
      avoided the extra fstat() for every open file by passing the dev_t and
      ino_t into lockFile.  This and the improvements to the locking
      algorithm result in a healthy 20% or so performance increase for
      opening/closing files (see openFile008 test).
  24. 18 Oct, 2007 1 commit
    • Simon Marlow's avatar
      add PIC relocations for x86_64, and use a simpler hack in place of x86_64_high_symbol() · 2fc88e73
      Simon Marlow authored
      This is Wolfgang Thaller's patch sent to cvs-ghc recently, with extra
      commentary by me.  It turns out that this patch is not just a cleanup,
      it is also necessary for GHCi to work on x86_64 with shared libraries,
      because previously lookupSymbol() was creating jump-table entries for
      all symbols looked up that resolved outside 2Gb, whereas Wolfgang's
      version only generates jump-table entries for 32-bit symbol references
      in object code that we load.
  25. 19 Oct, 2007 1 commit
  26. 11 Oct, 2007 1 commit
    • Simon Marlow's avatar
      Add a proper write barrier for MVars · 1ed01a87
      Simon Marlow authored
      Previously MVars were always on the mutable list of the old
      generation, which meant every MVar was visited during every minor GC.
      With lots of MVars hanging around, this gets expensive.  We addressed
      this problem for MUT_VARs (aka IORefs) a while ago, the solution is to
      use a traditional GC write-barrier when the object is modified.  This
      patch does the same thing for MVars.
      TVars are still done the old way, they could probably benefit from the
      same treatment too.
  27. 09 Oct, 2007 1 commit
  28. 05 Oct, 2007 1 commit
  29. 27 Sep, 2007 1 commit
  30. 16 Sep, 2007 2 commits
  31. 12 Sep, 2007 1 commit
  32. 05 Sep, 2007 1 commit
    • rl@cse.unsw.edu.au's avatar
      Use dlsym on OS X if available · 6f69004a
      rl@cse.unsw.edu.au authored
      On OS X 10.4 and newer, we have to use dlsym because the old NS* interface has
      been deprecated. The patch checks for HAVE_DLFCN_H instead of switching on
      the OS version.
      There is one additional quirk: although OS X prefixes global symbols with an
      underscore, dlsym expects its argument NOT to have a leading underscore. As a
      hack, we simply strip it off in lookupSymbol. Something a bit more elaborate
      might be cleaner.
  33. 03 Sep, 2007 1 commit
  34. 23 Aug, 2007 1 commit