This project is mirrored from Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 10 Apr, 2015 1 commit
  2. 03 Mar, 2015 1 commit
    • Tamar Christina's avatar
      Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64 · 5200bdeb
      Tamar Christina authored
      On Windows, the default action for things like division by zero and
      segfaults is to pop up a Dr. Watson error reporting dialog if the exception
      is unhandled by the user code.
      This is a pain when we are SSHed into a Windows machine, or when we
      want to debug a problem with gdb (gdb will get a first and second chance to
      handle the exception, but if it doesn't the pop-up will show).
      veh_excn provides two macros, `BEGIN_CATCH` and `END_CATCH`, which
      will catch such exceptions in the entire process and die by
      printing a message and calling `stg_exit(1)`.
      Previously this code was handled using SEH (Structured Exception Handlers)
      however each compiler and platform have different ways of dealing with SEH.
      `MSVC` compilers have the keywords `__try`, `__catch` and `__except` to have the
      compiler generate the appropriate SEH handler code for you.
      `MinGW` compilers have no such keywords and require you to manually set the
      SEH Handlers, however because SEH is implemented differently in x86 and x64
      the methods to use them in GCC differs.
      `x86`: SEH is based on the stack, the SEH handlers are available at `FS[0]`.
           On startup one would only need to add a new handler there. This has
           a number of issues such as hard to share handlers and it can be exploited.
      `x64`: In order to fix the issues with the way SEH worked in x86, on x64 SEH handlers
           are statically compiled and added to the .pdata section by the compiler.
           Instead of being thread global they can now be Image global since you have to
           specify the `RVA` of the region of code that the handlers govern.
      You can on x64 Dynamically allocate SEH handlers, but it seems that (based on
      experimentation and it's very under-documented) that the dynamic calls cannot override
      static SEH handlers in the .pdata section.
      Because of this and because GHC no longer needs to support < windows XP, the better
      alternative for handling errors would be using the in XP introduced VEH.
      The bonus is because VEH (Vectored Exception Handler) are a runtime construct the API
      is the same for both x86 and x64 (note that the Context object does contain CPU specific
      structures) and the calls are the same cross compilers. Which means this file can be
      simplified quite a bit.
      Using VEH also means we don't have to worry about the dynamic code generated by GHCi.
      Test Plan:
      Prior to this diff the tests for `derefnull` and `divbyzero` seem to have been disabled for windows.
      To reproduce the issue on x64:
      1) open ghci
      2) import GHC.Base
      3) run: 1 `divInt` 0
      which should lead to ghci crashing an a watson error box displaying.
      After applying the patch, run:
      make TEST="derefnull divbyzero"
      on both x64 and x86 builds of ghc to verify fix.
      Reviewers: simonmar, austin
      Reviewed By: austin
      Subscribers: thomie
      Differential Revision:
      GHC Trac Issues: #6079
  3. 05 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      Signed-off-by: default avatarEdward Z. Yang <>
      Test Plan: validate
      Reviewers: simonpj, simonmar, hvr, austin
      Subscribers: simonmar, relrod, carter
      Differential Revision:
  4. 07 Apr, 2014 1 commit
  5. 28 Jan, 2014 1 commit
  6. 07 Jan, 2014 1 commit
  7. 25 Oct, 2013 1 commit
  8. 11 Oct, 2013 1 commit
  9. 01 Oct, 2013 1 commit
  10. 22 Aug, 2013 1 commit
  11. 22 Jun, 2013 1 commit
  12. 21 Jun, 2013 1 commit
  13. 14 Jun, 2013 1 commit
  14. 10 May, 2013 1 commit
  15. 09 May, 2013 2 commits
  16. 29 Apr, 2013 1 commit
  17. 28 Apr, 2013 3 commits
  18. 26 Apr, 2013 1 commit
  19. 20 Apr, 2013 1 commit
  20. 06 Apr, 2013 1 commit
  21. 03 Apr, 2013 1 commit
    •'s avatar
      Fix installation · 6b431ab4 authored
      The build system thought that the RTS built more library files than
      it actually did, and installation failed when we tried to 'strip'
      one of these non-existant files.
  22. 24 Mar, 2013 1 commit
  23. 23 Mar, 2013 1 commit
    •'s avatar
      Change how we handle libffi · b30015e7 authored
      I think overall the new approach is simpler. Rather than unpacking
      the libffi.a and putting the .o files into our libHSrts.a, we just
      use the libffi.a.
      This change also means that when compiling programs for the dyn
      way, they get explicitly linked against (rather than
      relying on being linked against it). This might
      fix a problem on FreeBSD, where programs cannot find
  24. 21 Mar, 2013 1 commit
  25. 20 Mar, 2013 1 commit
    •'s avatar
      Fix build with non-Linux ELF OSes · 51bf3653 authored
      We were only setting an RPATH for the RTS DLL on Linux, but as far
      as I can see we should be doing it for all ELF OSes. Hopefully this
      will fix the problem where the installed ghc-pkg can't find libffi.dll
      on FreeBSD.
  26. 15 Mar, 2013 1 commit
  27. 03 Mar, 2013 2 commits
  28. 21 Feb, 2013 1 commit
  29. 17 Feb, 2013 2 commits
  30. 14 Feb, 2013 1 commit
  31. 29 Jan, 2013 1 commit
  32. 04 Jan, 2013 1 commit
    •'s avatar
      Add a -rpath entry for the RTS library, so that it can find libffi · 9d9d09de authored
      This fixes dynamic library resolution when --enable-new-dtags is used
      When --enable-new-dtags is used when linking an executable, a RUNPATH as
      well as RPATH is set. The linker then ignores RPATH, and RUNPATH is only
      used for directly (not transitively) needed libraries. As the program
      doesn't directly need libffi, it isn't found.
  33. 30 Nov, 2012 2 commits
  34. 29 Nov, 2012 1 commit
    •'s avatar
      Add configure option to use system provided libffi; fixes #5743 · 3005e909 authored
      Based on patch from Peter Trommler:
          From 293495d40f62e691520331a41c6d85d82e120169 Mon Sep 17 00:00:00 2001
          From: Peter Trommler <>
          Date: Sun, 21 Oct 2012 18:47:01 +0200
          Subject: [PATCH] Add configure option to use system provided libffi This
           fixes track # 5743 and #4496.