1. 03 Feb, 2018 1 commit
    • Ben Gamari's avatar
      ghc-prim: Emulate C11 atomics when not available · 217e4170
      Ben Gamari authored
      GCC's __sync primitives apparently "usually" imply a full barrier,
      meaning they can be used to emulate the more precise C11 atomics albeit
      with a loss of efficiency. This restores compatibility with GCC 4.4.
      
      This partially reverts commit 59de2909.
      
      Test Plan: Validate on Centos
      
      Reviewers: hvr, simonmar, trommler
      
      Subscribers: rwbarton, thomie, erikd, carter
      
      GHC Trac Issues: #14244
      
      Differential Revision: https://phabricator.haskell.org/D4364
      217e4170
  2. 15 Nov, 2017 1 commit
    • Peter Trommler's avatar
      RTS: Disable warnings in ffi.h · 8b1020ed
      Peter Trommler authored
      The update of GHC's in-tree libffi causes warnings about
      undefined macros and hence validate fails.
      
      Also mark broken tests that have a ticket.
      
      Fixes #14353
      
      Test Plan: ./validate (on AIX and powerpc if possible)
      
      Reviewers: bgamari, hvr, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, rwbarton, thomie
      
      GHC Trac Issues: #14353, #11259, #14455, #11261
      
      Differential Revision: https://phabricator.haskell.org/D4181
      8b1020ed
  3. 06 Nov, 2017 1 commit
    • Peter Trommler's avatar
      Update autoconf test for gcc to require 4.7 and up · 59de2909
      Peter Trommler authored
      Fixing #14244 required the newer gcc atomic built-ins that are provided
      from 4.7 and up. This updates the test to check for minimum gcc version
      4.7.
      
      The version tests for 3.4 (!), 4.4, and 4.6 are no longer needed and can
      be removed. This makes the build system simpler.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, hvr, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D4165
      59de2909
  4. 16 Oct, 2017 1 commit
  5. 05 Sep, 2017 1 commit
    • Tamar Christina's avatar
      Replace hashing function for string keys implementation with xxhash · 542f89ff
      Tamar Christina authored
      When doing profiling on startup time of ghci on Windows, both cold and
      startup loading static LLVM libs, the profiler is showing a glaring red
      spot on the division operation of the the hashStr function.
      
      In fact profiling shows 14% of the time is spent hashing the keys.
      
      So I am replacing the hash function with xxHash which is a very fast
      non-crypto hash. It's faster than MurMurHash which node etc use.
      
      It also passes SMHasher. I can provide if required the collected raw
      data.  But from analysis done on the keys, xxHash does not introduce
      more collisions than before, the amount splits seem about the same and
      the distributions among the buckets are slightly more uniform than
      before.
      
      However the runtime dropped enough to remove the function completely
      from the profiler's report.
      
      There's also a noticeable improvement in responsiveness.
      
      xxHash is BSD licensed and can be found
      https://github.com/Cyan4973/xxHash
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13165
      
      Differential Revision: https://phabricator.haskell.org/D3909
      542f89ff
  6. 29 Aug, 2017 1 commit
    • Tamar Christina's avatar
      Add gen-dll as replacement for dll-split · 5f6a8204
      Tamar Christina authored
      Summary:
      This tool can be used to generate dll's for any list of object files
      given to it. It will then repartition them automatically to fit within
      a dll and generates as many dll's as needed to do this. Cyclic dependencies
      between these generated dlls are handle automatically so there is no need
      to tell it how to partition.
      
      It is also a lot more general than `dll-split` as it is able to split any
      package not just `libGHC`. It also uses a trick using GNU style import libraries
      to hide the splitting from the rest of the pipeline. Which means come linking time
      you don't need to know which dll contains what symbol or how many split dlls were
      created.
      
      The import libraries are by default created with libtool. However since libtool is BFD
      based it is very slow. So if present and detected by configure the `genlib` tool
      from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
      
      To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
      
      More detailed explaination of the process can be found here
      https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
      
      GHC Trac Issues: #5987
      
      Differential Revision: https://phabricator.haskell.org/D3883
      5f6a8204
  7. 17 Aug, 2017 1 commit
  8. 11 May, 2017 1 commit
    • Ben Gamari's avatar
      rts: Don't build StgCRunAsm.S if unregisterised · aa8dcb33
      Ben Gamari authored
      StgCRunAsm.S provides StgCRun on powerpc64le platforms when
      registerised.  However, in the unregisterised setting we use the
      mini-interpreter and consequently shouldn't build StgCRunAsm.S lest we
      get duplicate symbols.
      
      Test Plan: Build unregisterised compiler on AIX.
      
      Reviewers: hvr, trommler, austin, simonmar
      
      Reviewed By: trommler, simonmar
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3560
      aa8dcb33
  9. 29 Apr, 2017 1 commit
  10. 23 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      rts: tweak cross-compilation to mingw32 · 745032dd
      Sergei Trofimovich authored
      Found the problem on x86_64-linux host where
      I tried to cross-compile GHC to windows as:
      
          $ ./configure --target=i686-w64-mingw32 \
                        Windres=i686-w64-mingw32-windres \
                        DllWrap=i686-w64-mingw32-dllwrap
      
      As a result build failed as POSIX bits of RTS.
      For example 'rts/posix/OSMem.c' contains unix-specific
      mmap() syscalls and constants and thus can't be compiled
      by i686-w64-mingw32 toolchain.
      
      It's caused by the following part of 'rts/ghc.mk':
      
        ifeq "$(HostOS_CPP)" "mingw32"
        ALL_DIRS += win32
        else
        ALL_DIRS += posix
        endif
      
      In our case _CPP variables are defined this way (project.mk):
        BuildOS_CPP                = linux
        HostOS_CPP                 = linux
        TargetOS_CPP               = mingw32
      
      RTS should never be built for 'BuildOS' or 'HostOS' as it's
      always built by ghc-stage1 (targeted at TargetOS).
      
      The change is to flip 'HostOS_CPP' to 'TargetOS_CPP' in 'rts/ghc.mk'.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      745032dd
  11. 05 Apr, 2017 1 commit
  12. 04 Apr, 2017 1 commit
  13. 28 Feb, 2017 1 commit
    • Moritz Angermann's avatar
      Drop copy step from the rts/ghc.mk · 3e33d334
      Moritz Angermann authored
      Recently I've used a different build system for building the
      rts (Xcode).  And in doing so, I looked through the rts/ghc.mk
      to figure out how to build the rts.
      
      In general it's quite straight forward to just compile all the
      c files with the proper flags.
      
      However there is one rather awkward copy step that copies some
      files for special handling for the rts way.
      
      I'm wondering if the proposed solution in this diff is better
      or worse than the current situation?
      
      The idea is to keep the files, but use #includes to produce
      identical files with just an additional define. It does however
      produce empty objects for non threaded ways.
      
      Reviewers: ezyang, bgamari, austin, erikd, simonmar, rwbarton
      
      Reviewed By: bgamari, simonmar, rwbarton
      
      Subscribers: rwbarton, thomie, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3237
      3e33d334
  14. 12 Feb, 2017 1 commit
    • olsner's avatar
      Apply SplitSections to all C compilations · a50082c1
      olsner authored
      Previously this was added only to the RTS's C files (those are the bulk
      of it though), but there are C bits in ghc-prim, integer-gmp and base
      too.
      
      Followup for #8405, allows the large table of character properties in
      base to be stripped when not used.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: thomie, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3121
      a50082c1
  15. 21 Oct, 2016 1 commit
  16. 31 May, 2016 1 commit
  17. 24 May, 2016 1 commit
    • Erik de Castro Lopo's avatar
      Runtime linker: Break m32 allocator out into its own file · fe8a4e5d
      Erik de Castro Lopo authored
      This makes the code a little more modular and allows the removal of some
      CPP hackery. By providing dummy implementations of of the `m32_*`
      functions (which simply call `errorBelch`) it means that the call sites
      for these functions are syntax checked even when `RTS_LINKER_USE_MMAP`
      is `0`.
      
      Also changes some size parameter types from `unsigned int` to `size_t`.
      
      Test Plan: Validate on Linux, OS X and Windows
      
      Reviewers: Phyx, hsyl20, bgamari, simonmar, austin
      
      Reviewed By: simonmar, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2237
      fe8a4e5d
  18. 16 Apr, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Rework CC/CC_STAGE0 handling in `configure.ac` · 865602e0
      Herbert Valerio Riedel authored
      Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
      scheme use the `CC=...` style scheme.
      
      The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
      stage{1,2,3}, while having a separate _STAGE0 set of env-vars
      denote the bootstrap-toolchain flags/programs.
      
      This should be simpler, less confusing, and somewhat more in line with
      Autoconf's idioms (allowing us to reuse more of Autoconf rather than
      (re)inventing our own confusing non-standard m4 macros to do stuff that
      Autoconf could almost do already for us)
      
      Morever, expose CC_STAGE0 as a so-called "precious" variable.
      
      So now we can better control which bootstrapping gcc is used
      (by default the one used by the stage0 ghc, unless CC_STAGE0 is
      overriden)
      
      ```
      Some influential environment variables:
        CC_STAGE0   C compiler command (bootstrap)
        CC          C compiler command
        CFLAGS      C compiler flags
        ...
      
      Use these variables to override the choices made by `configure' or to
      help it to find libraries and programs with nonstandard names/locations.
      ```
      
      Test Plan: I've tested that cross-compiling with
      `--target=powerpc-linux-gnu` still works, and tried a few variants of
      settting `CC=` and `CC_STAGE0=`; `./validate` passed as well
      
      Reviewers: erikd, austin, bgamari, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2078
      865602e0
  19. 24 Mar, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Add NCG support for AIX/ppc32 · df26b955
      Herbert Valerio Riedel authored
      This extends the previous work to revive the unregisterised GHC build
      for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later)
      hardware, but the PPC32 instructions implemented in the PPC NCG
      represent a compatible subset of the POWER4 ISA.
      
      IBM AIX follows the PowerOpen ABI (and shares many similiarites with the
      Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF
      format (compared to ELF).
      
      This doesn't support dynamic libraries yet.
      
      A major limiting factor is that the AIX assembler does not support the
      `@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's
      assembler supports. Therefore we need to avoid emitting those. In case
      of numeric literals we simply compute the functions ourselves, while for
      labels we have to use local TOCs and hope everything fits into a 16bit
      offset (for ppc32 this gives us at most 16384 entries per TOC section,
      which is enough to compile GHC).
      
      Another issue is that XCOFF doesn't seem to have a relocation type for
      label-differences, and therefore the label-differences placed into
      tables-next-to-code can't be relocated, but the linker may rearrange
      different sections, so we need to place all read-only sections into the
      same `.text[PR]` section to workaround this.
      
      Finally, the PowerOpen ABI distinguishes between function-descriptors
      and actualy entry-point addresses. For AIX we need to be specific when
      emitting assembler code whether we want the address of the function
      descriptor `printf`) or for the entry-point (`.printf`). So we let the
      asm pretty-printer prefix a dot to all emitted subroutine
      calls (i.e. `BL`) on AIX only. For now, STG routines' entry-point labels
      are not prefixed by a label and don't have any associated
      function-descriptor.
      
      Reviewers: austin, trommler, erikd, bgamari
      
      Reviewed By: trommler, erikd, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D2019
      df26b955
  20. 27 Jan, 2016 1 commit
  21. 18 Jan, 2016 1 commit
    • Edward Z. Yang's avatar
      Switch from -this-package-key to -this-unit-id. · 240ddd7c
      Edward Z. Yang authored
      A small cosmetic change, but we have to do a bit of work to
      actually support it:
      
          - Cabal submodule update, so that Cabal passes us
            -this-unit-id when we ask for it.  This includes
            a Cabal renaming to be consistent with Unit ID, which
            makes ghc-pkg a bit more scrutable.
      
          - Build system is updated to use -this-unit-id rather than
            -this-package-key, to avoid deprecation warnings.  Needs
            a version test so I resurrected the old test we had
            (sorry rwbarton!)
      
          - I've *undeprecated* -package-name, so that we are in the same
            state as GHC 7.10, since the "correct" flag will have only
            entered circulation in GHC 8.0.
      
          - I removed -package-key.  Since we didn't deprecate -package-id
            I think this should not cause any problems for users; they
            can just change their code to use -package-id.
      
          - The package database is indexed by UNIT IDs, not component IDs.
            I updated the naming here.
      
          - I dropped the signatures field from ExposedModule; nothing
            was using it, and instantiatedWith from the package database
            field.
      
          - ghc-pkg was updated to use unit ID nomenclature, I removed
            the -package-key flags but I decided not to add any new flags
            for now.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: 23Skidoo, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1780
      240ddd7c
  22. 18 Nov, 2015 1 commit
  23. 12 Nov, 2015 1 commit
    • olsner's avatar
      Implement function-sections for Haskell code, #8405 · 4a32bf92
      olsner authored
      This adds a flag -split-sections that does similar things to
      -split-objs, but using sections in single object files instead of
      relying on the Satanic Splitter and other abominations. This is very
      similar to the GCC flags -ffunction-sections and -fdata-sections.
      
      The --gc-sections linker flag, which allows unused sections to actually
      be removed, is added to all link commands (if the linker supports it) so
      that space savings from having base compiled with sections can be
      realized.
      
      Supported both in LLVM and the native code-gen, in theory for all
      architectures, but really tested on x86 only.
      
      In the GHC build, a new SplitSections variable enables -split-sections
      for relevant parts of the build.
      
      Test Plan: validate with both settings of SplitSections
      
      Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari
      
      Reviewed By: simonmar, thomie, bgamari
      
      Subscribers: hsyl20, erikd, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1242
      
      GHC Trac Issues: #8405
      4a32bf92
  24. 07 Nov, 2015 1 commit
    • Tamar Christina's avatar
      Allow the GHCi Linker to resolve related dependencies when loading DLLs · 6e6438e1
      Tamar Christina authored
      Summary:
      GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's
      that are not on the standard Windows load path:
      
      1. The directory from which the application loaded.
      2. The current directory.
      3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
      4. The 16-bit system directory. There is no function that obtains the path of this directory,
         but it is searched.
      5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
      6. The directories that are listed in the PATH environment variable.
         Note that this does not include the per-application path specified by the
         AppPaths registry key. The App Paths key is not used when computing the DLL search path.
      
      So what this means is given two DLLs `A` and `B` and `B` depending on `A`.
      If we put both DLLs into a new folder bin and then call GHC with:
      
      `ghc -L$(PWD)/bin -lB`
      
      the loading will fail as the Windows loader will try to load the dependency of `B` and fail
      since it cannot find `A`.
      
      *IMPORTANT* this patch drops XP Support.
      The  APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista
      via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has
      not been installed on certain machines. For those machines I display a warning and
      temporarily expand the `PATH` to allow it to load.
      
      This patch will make sure that paths provided by the user with `-L` *and* the folder in which a
      DLL is found are added to the search path. It does so using one of two methods depending upon how
      new of a Windows version we are running on:
      
      - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`.
         The order of which these directories are searched is nondeterministic.
      - If the APIs are not available it means that we're running on a pretty old unpatched machine.
        But if it's being used in an environment with no internet access it may be the case.
        So if the APIs are not available we temporarily extend the `PATH` with the directories.
        A warning is also displayed to the user informing them that the linking may fail,
        and if it does, install the needed patch. The `PATH` variable has limitations.
      
      Test Plan:
      ./validate
      
      Added two new test T10955 and T10955dyn
      
      Reviewers: erikd, bgamari, thomie, hvr, austin
      
      Reviewed By: erikd, thomie
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1340
      
      GHC Trac Issues: #10955
      6e6438e1
  25. 17 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Libdw: Add libdw-based stack unwinding · a6a3dabc
      Ben Gamari authored
      This adds basic support to the RTS for DWARF-assisted unwinding of the
      Haskell and C stack via libdw. This only adds the infrastructure;
      consumers of this functionality will be introduced in future diffs.
      
      Currently we are carrying the initial register collection code in
      Libdw.c but this will eventually make its way upstream to libdw.
      
      Test Plan: See future patches
      
      Reviewers: Tarrasch, scpmw, austin, simonmar
      
      Reviewed By: austin, simonmar
      
      Subscribers: simonmar, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1196
      
      GHC Trac Issues: #10656
      a6a3dabc
  26. 21 Aug, 2015 1 commit
    • thomie's avatar
      Build system: simplify install.mk.in · 47493e60
      thomie authored
      This will allow fixing #1851 more easily
      ("make install-strip" should work).
      
      This reverts 57e2a81c:
        "On Cygwin, use a Cygwin-style path for /bin/install's destination"
      
      Update submodule haddock and hsc2hs.
      47493e60
  27. 03 Jul, 2015 1 commit
    • Peter Trommler's avatar
      Implement PowerPC 64-bit native code backend for Linux · d3c1dda6
      Peter Trommler authored
      Extend the PowerPC 32-bit native code generator for "64-bit
      PowerPC ELF Application Binary Interface Supplement 1.9" by
      Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
      OpenPOWER ABI for Linux Supplement" by IBM.
      The latter ABI is mainly used on POWER7/7+ and POWER8
      Linux systems running in little-endian mode. The code generator
      supports both static and dynamic linking. PowerPC 64-bit
      code for ELF ABI 1.9 and 2 is mostly position independent
      anyway, and thus so is all the code emitted by the code
      generator. In other words, -fPIC does not make a difference.
      
      rts/stg/SMP.h support is implemented.
      
      Following the spirit of the introductory comment in
      PPC/CodeGen.hs, the rest of the code is a straightforward
      extension of the 32-bit implementation.
      
      Limitations:
      * Code is generated only in the medium code model, which
        is also gcc's default
      * Local symbols are not accessed directly, which seems to
        also be the case for 32-bit
      * LLVM does not work, but this does not work on 32-bit either
      * Must use the system runtime linker in GHCi, because the
        GHC linker for "static" object files (rts/Linker.c) for
        PPC 64-bit is not implemented. The system runtime
        (dynamic) linker works.
      * The handling of the system stack (register 1) is not ELF-
        compliant so stack traces break. Instead of allocating a new
        stack frame, spill code should use the "official" spill area
        in the current stack frame and deallocation code should restore
        the back chain
      * DWARF support is missing
      
      Fixes #9863
      
      Test Plan: validate (on powerpc, too)
      
      Reviewers: simonmar, trofi, erikd, austin
      
      Reviewed By: trofi
      
      Subscribers: bgamari, arnons1, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D629
      
      GHC Trac Issues: #9863
      d3c1dda6
  28. 22 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Rename $1_$2_$3_LIB_NAME to LIB_FILE. · 01f7e440
      Edward Z. Yang authored
      Summary:
      When we introduced user-friendly library names
      (e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of
      unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to
      be written out by ghc-cabal, $1_$2_LIB_NAME.
      
      What I didn't realize at the time was that this conflicts
      with an existing variable in the build system, $1_$2_$3_LIB_NAME,
      which (confusingly) refers to something like
      'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'.  This is pretty
      confusing (despite never conflicting), so I renamed this variable
      to LIB_FILE for enhanced greppability.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: austin
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1002
      01f7e440
  29. 10 Apr, 2015 1 commit
  30. 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
      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
  31. 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
      explosion.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D80
      66218d15
  32. 07 Apr, 2014 1 commit
  33. 28 Jan, 2014 1 commit
  34. 07 Jan, 2014 1 commit
  35. 25 Oct, 2013 1 commit
  36. 11 Oct, 2013 1 commit
  37. 01 Oct, 2013 1 commit
  38. 22 Aug, 2013 1 commit
  39. 22 Jun, 2013 1 commit
  40. 21 Jun, 2013 1 commit