1. 03 Mar, 2015 2 commits
    • thomie's avatar
      Pretty-print # on unboxed literals in core · 89458eba
      thomie authored
      Summary:
      Ticket #10104 dealt with showing the '#'s on types with unboxed fields. This
      commit pretty prints the '#'s on unboxed literals in core output.
      
      Test Plan: simplCore/should_compile/T8274
      
      Reviewers: jstolarek, simonpj, austin
      
      Reviewed By: simonpj, austin
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D678
      
      GHC Trac Issues: #8274
      89458eba
    • Tamar Christina's avatar
      Replaced SEH handles with VEH handlers which should work uniformly across x86 and x64 · 5200bdeb
      Tamar Christina authored
      Summary:
      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: https://phabricator.haskell.org/D691
      
      GHC Trac Issues: #6079
      5200bdeb
  2. 02 Mar, 2015 18 commits
  3. 27 Feb, 2015 1 commit
  4. 26 Feb, 2015 1 commit
  5. 24 Feb, 2015 4 commits
  6. 23 Feb, 2015 14 commits