1. 26 Jan, 2018 1 commit
    • Tamar Christina's avatar
      Fix Windows stack allocations. · a55d581f
      Tamar Christina authored
      On Windows we use the function `win32AllocStack` to do stack
      allocations in 4k blocks and insert a stack check afterwards
      to ensure the allocation returned a valid block.
      The problem is this function does something that by C semantics
      is pointless. The stack allocated value can never escape the
      function, and the stack isn't used so the compiler just optimizes
      away the entire function body.
      After considering a bunch of other possibilities I think the simplest
      fix is to just disable optimizations for the function.
      Alternatively inline assembly is an option but the stack check function
      doesn't have a very portable name as it relies on e.g. `libgcc`.
      Thanks to Sergey Vinokurov for helping diagnose and test.
      Test Plan: ./validate
      Reviewers: bgamari, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #14669
      Differential Revision: https://phabricator.haskell.org/D4343
  2. 19 Dec, 2017 1 commit
  3. 29 Apr, 2017 1 commit
  4. 08 Feb, 2017 1 commit
  5. 28 Nov, 2016 1 commit
  6. 05 Jul, 2016 1 commit
    • Moritz Angermann's avatar
      Adds x86_64-apple-darwin14 target. · f560a03c
      Moritz Angermann authored
      x86_64-apple-darwin14, is the target for the 64bit simulator.
      Ideally, we'd have (i386|armv7|arm64|x64_86)-apple-ios, yet,
      many #ifdefs depend on `darwin`, notably libffi. Hence, this only adds
      x86_64-apple-darwin14 as a target. This also updates the comment to
      add the `-S` flag, and dump the output to stdout; and adjusts the
      `datalayout` and `triple` values, as obtained through the method
      mentioned in the comment.
      Reviewers: hvr, erikd, austin, bgamari, simonmar
      Reviewed By: simonmar
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2378
  7. 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
      Reviewers: austin, trommler, erikd, bgamari
      Reviewed By: trommler, erikd, bgamari
      Differential Revision: https://phabricator.haskell.org/D2019
  8. 01 Nov, 2015 1 commit
    • Ben Gamari's avatar
      StgStartup: Setup unwinding for stg_stop_thread · d9f88628
      Ben Gamari authored
      This is a bit ugly as we need to assume the structure of the C stack as
      left by StgRun. Nevertheless, it allows us to unwind all the way back to
      `_start` on my machine.
      Stack trace:
          set_initial_registers (rts/Libdw.c:272.0)
          libdw_get_backtrace (rts/Libdw.c:243.0)
          base_GHCziBase_bindIO1_info (libraries/base/GHC/Base.hs:1085.1)
          base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
          base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
          base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
          base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
          base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1)
          stg_catch_frame_info (rts/Exception.cmm:370.1)
          stg_stop_thread_info (rts/StgStartup.cmm:42.1)
          scheduleWaitThread (rts/Schedule.c:465.0)
          hs_main (rts/RtsMain.c:65.0)
          __libc_start_main (/tmp/buildd/glibc-2.19/csu/libc-start.c:321.0)
  9. 03 Aug, 2015 1 commit
    • Ben Gamari's avatar
      Fix incorrect stack pointer usage in StgRun() on x86_64 · b38ee89c
      Ben Gamari authored
      The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants
      where the ABI doesn't impose a mandatory red zone for the stack, like on
      Windows or Xen/HaLVM. The current implementation restores the stack
      pointer first, which effectively marks the area with the saved registers
      as reusable. Later, the CPU registers are restored from this "free"
      This ordering happens to work by accident on operating systems that
      strictly adhere to the System V ABI, because any interrupt/signal
      delivery is guaranteed to leave the first 128 bytes past the stack
      pointer untouched (red zone). On other systems this might result in
      corrupted CPU registers if an interruption happens just after restoring
      the stack pointer.
      The red zone is usually only used by small leaf functions to avoid
      updates to the stack pointer and exploiting it doesn't give us any
      advantage in this case.
      Reviewers: austin, rwbarton
      Reviewed By: rwbarton
      Subscribers: thomie, simonmar
      Differential Revision: https://phabricator.haskell.org/D1120
      GHC Trac Issues: #10155
  10. 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.
      * 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
  11. 23 May, 2015 1 commit
  12. 26 Jan, 2015 1 commit
  13. 19 Nov, 2014 1 commit
  14. 29 Sep, 2014 1 commit
  15. 28 Jul, 2014 1 commit
  16. 22 Apr, 2014 1 commit
  17. 24 Aug, 2013 1 commit
  18. 27 Apr, 2013 2 commits
  19. 02 Mar, 2013 3 commits
  20. 01 Nov, 2012 1 commit
  21. 24 Mar, 2012 1 commit
  22. 23 Mar, 2012 1 commit
  23. 19 Mar, 2012 2 commits
  24. 18 Mar, 2012 1 commit
  25. 16 Feb, 2012 2 commits
  26. 07 Feb, 2012 1 commit
  27. 30 Jan, 2012 1 commit
  28. 05 Jan, 2012 1 commit
  29. 19 Dec, 2011 1 commit
    • dmp's avatar
      Hide STG register declarations for LLVM C compilers · f542da48
      dmp authored
      This commit swaps the import order of Rts.h and Stg.h in
      StgCRun.c for non-SPARC architectures. Swapping the import
      order prevents the declaration of the global registers thus
      allowing the GHC runtime to be compiled by LLVM-based C
      LLVM-base C compilers cannot use the global register
      declarations (for R1, R2, etc.) because they use
      GCC-specific extensions. The declarations are not needed in
      StgCRun.c except for the SPARC architecture. The other
      architectures use hand-written assembly that accesses the
      appropriate register directly.
  30. 22 Nov, 2011 1 commit
  31. 17 Nov, 2011 3 commits
  32. 01 Nov, 2011 1 commit
    • dmp's avatar
      Change stack alignment to 16+8 bytes in STG code · a9ce3611
      dmp authored
      This patch changes the STG code so that %rsp to be aligned
      to a 16-byte boundary + 8. This is the alignment required by
      the x86_64 ABI on entry to a function. Previously we kept
      %rsp aligned to a 16-byte boundary, but this was causing
      problems for the LLVM backend (see #4211
      We now don't need to invoke llvm stack mangler on
      x86_64 targets. Since the stack is now 16+8 byte algined in
      STG land on x86_64, we don't need to mangle the stack
      manipulations with the llvm mangler.
      This patch only modifies the alignement for x86_64 backends.
      Signed-off-by: dterei's avatarDavid Terei <davidterei@gmail.com>
  33. 07 Oct, 2011 1 commit
    • dmp's avatar
      Enable pthread_getspecific() tls for LLVM compiler · dba72545
      dmp authored
      LLVM does not support the __thread attribute for thread
      local storage and may generate incorrect code for global
      register variables. We want to allow building the runtime with
      LLVM-based compilers such as llvm-gcc and clang,
      particularly for MacOS.
      This patch changes the gct variable used by the garbage
      collector to use pthread_getspecific() for thread local
      storage when an llvm based compiler is used to build the