1. 25 Apr, 2017 2 commits
  2. 23 Apr, 2017 1 commit
  3. 17 Apr, 2017 1 commit
  4. 06 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      Use non-canocalized triple as cross-compiler prefix · 844704b4
      Sergei Trofimovich authored
      
      
      I've noticed the problem when tried to install
      cross-compiler using following configuration:
      
          $ ./configure --target=s390x-unknown-linux-gnu
          make install Stage1Only=YES
      
      Instead of expected tool prefix
          's390x-unknown-linux-gnu-'
      Result was:
          's390x-ibm-linux-gnu-'
      
      It's problematic as installed binaries appear in
      unpredictable location.
      
      The problem is caused by use of ${target} autoconf variable.
      ${target} contains a canocalized triplet.
      
      Luckily we already have non-canonucalized target triplet
      in ${TargetPlatformFull} variable. The change uses that
      instead.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      844704b4
  5. 02 Apr, 2017 2 commits
  6. 29 Mar, 2017 1 commit
  7. 27 Mar, 2017 1 commit
    • Moritz Angermann's avatar
      Adds aarch64 linker for mach-o files. · e8a27410
      Moritz Angermann authored
      This is the final commit that ties them all together. Here we
      add the aarch64 linker for macho files.
      
      - In D3238 we started allowing preloading object code with mmap
        in iOS, where we can't have r+w+x.
      - In D3239 we introduced a richer extension of the object code
        data type to make working with mach-o files easier.
      - In D3240 we set the stage to allow loading archives (.a) on iOS
      - In D3251 we added init and deinit functions to populate and
        depopulate the enriched object code data structure for mach-o
        files.
      - In D3252 we refactored most of the MachO.c file to use the
        new types and datastructure.
      
      This commit will than finally add the aarch64 (arm64) linker
      for mach-o files to ghc, using the improved foundation we
      have constructed above.
      
      The dependency structure therefore is as follows
      
      ```
        .- D3240
        v
      This <- D3252 <- D3251 <- D3239
        ^
        '- D3238
      ```
      
      Depends: D3252, D3240, D3238
      
      Test Plan:
      To test this with iOS, we also need the remote-iserv
      diff D3233. With all that in place, proceed as follows:
      
      - Build ghc for the host
      
      ```
        ghc $ ./configure --prefix=/test/opt \
          --disable-large-address-space \
          --with-llc=/path/to/llvm-3.9/bin/llc \
          --with-opt=/path/to/llvm-3.9/bin/opt
        # edit mk/build.mk to specify quick
        ghc $ make && make install
      ```
      
      - Build ghc for ios
      
      ```
        ghc $ ./configure --target=aarch64-apple-darwin14 \
          --prefix=/test/opt \
          --disable-large-address-space \
          --with-llc=/path/to/llvm-3.9/bin/llc \
          --with-opt=/path/to/llvm-3.9/bin/opt \
          --with-ghc=/test/bin/ghc \
          --enable-bootstrap-with-devel-snapshot
        # edit mk/build.mk to specify quick-cross
        ghc $ make && make install
      
      ```
      - Obtain the iOS wrapper scripts from
      https://github.com/angerman/ghc-ios-scripts
        and place them in PATH.
      
      - Build iserv-proxy for the host
      
      ```
        ghc/iserv $ cabal install -fproxy -flibrary
      
      ```
      - Build iserv-library for the target
      
      ```
        # build cryptonite without integer-gmp
        ghc/iserv $ aarch64-apple-darwin14-cabal install cryptonite
      -f-integer-gmp
        ghc/iserv $ aarch64-apple-darwin14-cabal install -flibrary
      ```
      
      - Create an iOS application with the following `main.m`:
      ```
        #import <UIKit/UIKit.h>
        #include "HsFFI.h"
        extern void startSlave(bool, int, const char *);
      
        int main(int argc, char * argv[]) {
          const char * documents_path = [[[NSFileManager defaultManager]
      URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask]
      firstObject].path.UTF8String;
      
          hs_init(NULL, NULL);
      
          startSlave(false, 5000, documents_path);
      
          @autoreleasepool {
              return UIApplicationMain(argc, argv, nil, nil);
          }
        }
      ```
      
        and link it with: the iserv archive from
      `~/.cabal/lib/aarch64-ios-ghc`
        as well as all dependent archives.
      
      - Build, Install and Launch the iserv-slave application on your iphone
      
      - Compile some Template Haskell code with the
      `aarch64-apple-darwin14-ghc`,
        through the `iserv-proxy`
      
      ```
        app $ aarch64-apple-darwin14-ghc Module.hs \
         -threaded -staticlib \
         -outputdir build/aarch64 -pgmlibtool libtool-quiet -stubdir . \
         -fexternal-interpreter \
         -pgmi=$HOME/.cabal/bin/iserv-proxy \
         -opti10.0.0.1 \
         -opti5000
      ```
        where 10.0.0.1 is the ip of your iserv-slave.
      
        magic.
      
      Reviewers: rwbarton, bgamari, austin, hvr, erikd, simonmar
      
      Subscribers: thomie, erikd, ryantrinkle
      
      Differential Revision: https://phabricator.haskell.org/D3255
      e8a27410
  8. 24 Mar, 2017 1 commit
  9. 10 Mar, 2017 1 commit
  10. 09 Mar, 2017 3 commits
  11. 07 Mar, 2017 1 commit
  12. 04 Mar, 2017 1 commit
  13. 28 Feb, 2017 1 commit
    • Ben Gamari's avatar
      configure: detect whether -lpthreads is necessary for pthreads · e94bfb67
      Ben Gamari authored
      Some platforms have pthreads support available without linking against
      libpthread (and indeed don't even offer a libpthread to link against).
      One example of this is Android's bionic library. Teach the RTS about
      this case.
      
      Test Plan: Validate while cross-compiling targetting Android on aarch64
      
      Reviewers: simonmar, austin, hvr, erikd, rwbarton
      
      Subscribers: danharaj, thomie, erikd, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3149
      e94bfb67
  14. 26 Feb, 2017 1 commit
  15. 22 Jan, 2017 1 commit
  16. 20 Jan, 2017 1 commit
  17. 19 Jan, 2017 1 commit
  18. 17 Jan, 2017 1 commit
  19. 10 Jan, 2017 1 commit
  20. 27 Dec, 2016 1 commit
    • Peter Trommler's avatar
      Testsuite: Skip failing tests on PowerPC 64-bit · 4dec7d19
      Peter Trommler authored
      The Power ISA says the result of a division by zero is undefined.  So
      ignore stdout on PowerPC 64-bit systems.
      
      Disable ext-interp tests on 64-bit PowerPC.  We don't have support for
      PowerPC 64-bit ELF in the RTS linker, which is needed for the external
      interpreter.
      
      Test Plan: ./validate
      
      Reviewers: austin, simonmar, hvr, erikd, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2782
      4dec7d19
  21. 18 Nov, 2016 1 commit
  22. 17 Nov, 2016 1 commit
  23. 11 Nov, 2016 2 commits
    • Ben Gamari's avatar
      Pass -no-pie to GCC · d421a7e2
      Ben Gamari authored
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      
      This is a second attempt at D2691. This attempt constrasts with D2691 in that
      it preserves the "does gcc support -no-pie" flag in settings, allowing this to
      be reconfigured by `configure` during installation of a binary distribution.
      Thanks for @rwbarton for drawing attention to this issue.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, erikd
      
      Reviewed By: erikd
      
      Subscribers: thomie, rwbarton, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2693
      
      GHC Trac Issues: #12759
      d421a7e2
    • Ben Gamari's avatar
      Revert "Pass -no-pie to GCC" · 60bb9d1c
      Ben Gamari authored
      This reverts commit bae4a55b.
      
      This will be superceded by D2693.
      60bb9d1c
  24. 10 Nov, 2016 3 commits
  25. 22 Oct, 2016 1 commit
    • Darshan Kapashi's avatar
      rts: configure.ac should populate HAVE_LIBNUMA instead of USE_LIBNUMA · 1050e46b
      Darshan Kapashi authored
      Code in rts/ which deals with numa checks for `#if HAVE_LIBNUMA`,
      however this macro is not populated during `./configure`.
      https://phabricator.haskell.org/D2329 changed this code last and we
      instead set `USE_LIBNUMA` which fails to setup numa correctly.
      
      Test Plan:
      From main directory in ghc,
      
        ./configure && make clean && make boot && make
        cd nofib/parallel/queens
        ../../../inplace/bin/ghc-stage2 Main.hs -rtsopts -threaded
        ./Main 15 +RTS -N24 -s -A64m --numa
      
      This fails before this patch with
      
        Main: --numa: OS reports NUMA is not available
      
      After the fix, it works as expected.
      
      Run the validation script,
      
        ./validate
      
      (It fails with an error in `compiler/utils/Util.hs` saying
      `GHC.Stack.CallStack` not found, once I remove this 1 line from this
      file , the script works)
      
      Reviewers: hvr, austin, bgamari, erikd, simonmar
      
      Reviewed By: erikd, simonmar
      
      Subscribers: mpickering, thomie, erikd, niteria
      
      Differential Revision: https://phabricator.haskell.org/D2620
      
      GHC Trac Issues: #12741
      1050e46b
  26. 19 Oct, 2016 1 commit
  27. 02 Sep, 2016 1 commit
    • Sergei Trofimovich's avatar
      configure.ac: fix --host= handling · 0cc3931b
      Sergei Trofimovich authored
      The following command fails as:
          $ ./configure --prefix=/usr \
              --build=x86_64-pc-linux-gnu \
              --host=x86_64-pc-linux-gnu \
              --target=x86_64-pc-linux-gnu
          configure: error:
          You've selected:
      
            BUILD:  x86_64-unknown-linux
            HOST:   x86_64-unknown-linux
            TARGET: x86_64-unknown-linux
      
          BUILD must equal HOST;
      
      18f06878
      
       changed native
      configure $build/$host/$target checks to ghc-mangled ones,
      but not completely.
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Reviewers: rwbarton, erikd, austin, hvr, bgamari, Phyx
      
      Reviewed By: Phyx
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2508
      
      GHC Trac Issues: #12487
      0cc3931b
  28. 15 Aug, 2016 1 commit
  29. 14 Aug, 2016 1 commit
    • Tamar Christina's avatar
      Fix configure detection. · 18f06878
      Tamar Christina authored
      Summary:
      GHC's configure script seems to normalize the values returned from config.guess.
      So for Windows it turns x86_64-pc-mingw64 into x86_64-unknown-mingw32.
      These mangled names are stored in the values $BuildPlatform, $HostPlatform
      and $TargetPlatform.
      
      However further down the file when the comparison is done between the stage0
      compiler and the host the normalized versions are not used.
      So when normalization actually changes the triple this check will fail.
      
      Not sure why it's worked for all this time.. Nor if this is the right fix?
      Does it still work for cross compiling correctly?
      
      Test Plan: ./configure
      
      Reviewers: hvr, austin, thomie, bgamari, erikd
      
      Reviewed By: erikd
      
      Subscribers: erikd, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2452
      
      GHC Trac Issues: #12487
      18f06878
  30. 06 Aug, 2016 1 commit
  31. 06 Jul, 2016 1 commit
  32. 13 Jun, 2016 1 commit
    • Erik de Castro Lopo's avatar
      rts: Fix NUMA when cross compiling · 2bb6ba62
      Erik de Castro Lopo authored
      The NUMA code was enabled whenever numa.h and numaif.h are detected.
      Unfortunately, the hosts' header files were being detected even then
      cross compiling in the absence of a target libnuma.
      
      Fix that by relying on the the presence of libnuma instead of the
      presence of the header files. The test for libnuma does `AC_TRY_LINK`
      which will fail if the test program (compiled for the target) can't
      be linked against libnuma.
      
      Test Plan:
      Build on x86_64/linux and make sure NUMA works and cross compile to
      armhf/linux.
      
      Reviewers: austin, bgamari, hvr, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2329
      2bb6ba62
  33. 10 Jun, 2016 1 commit
    • Simon Marlow's avatar
      NUMA support · 9e5ea67e
      Simon Marlow authored
      Summary:
      The aim here is to reduce the number of remote memory accesses on
      systems with a NUMA memory architecture, typically multi-socket servers.
      
      Linux provides a NUMA API for doing two things:
      * Allocating memory local to a particular node
      * Binding a thread to a particular node
      
      When given the +RTS --numa flag, the runtime will
      * Determine the number of NUMA nodes (N) by querying the OS
      * Assign capabilities to nodes, so cap C is on node C%N
      * Bind worker threads on a capability to the correct node
      * Keep a separate free lists in the block layer for each node
      * Allocate the nursery for a capability from node-local memory
      * Allocate blocks in the GC from node-local memory
      
      For example, using nofib/parallel/queens on a 24-core 2-socket machine:
      
      ```
      $ ./Main 15 +RTS -N24 -s -A64m
        Total   time  173.960s  (  7.467s elapsed)
      
      $ ./Main 15 +RTS -N24 -s -A64m --numa
        Total   time  150.836s  (  6.423s elapsed)
      ```
      
      The biggest win here is expected to be allocating from node-local
      memory, so th...
      9e5ea67e