1. 12 Aug, 2015 1 commit
    • Tamar Christina's avatar
      Upgrade GCC to 5.2.0 for Windows x86 and x86_64 · 7b211b4e
      Tamar Christina authored
      This patch does a few things
      
      - Moved GHC x86 to MinGW-w64 (Using Awson's patch)
      - Moves Both GHCs to MSYS2 toolchains
      - Completely removes the dependencies on the git tarball repo
        - Downloads only the required tarball for the architecture for
          which we are building
        - Downloads the perl tarball is missing as well
        - Fixed a few bugs in the linker to fix tests on Windows
      
      The links currently point to repo.msys2.org and GitHub, it might be
      more desirable to mirror them on
      http://downloads.haskell.org/~ghc/mingw/ as with the previous patch
      attempt.
      
      For more details on what the MSYS2 packages I include see #10726
      (Awson's comment). but it should contain all we need
      and no python or fortran, which makes the uncompressed tar a 1-2
      hundreds mb smaller.
      
      The `GCC 5.2.0` in the package supports `libgcc` as a shared library,
      this is a problem since
      when compiling with -shared the produced dll now has a dependency on
      `libgcc_s_sjlj-1.dll`.
      To solve this the flag `-static-libgcc` is now being used for all GCC
      calls on windows.
      
      Test Plan:
      ./validate was ran both on x86 and x86_64 windows and compared against
      the baseline.
      
      A few test were failing due to Ld no longer being noisy. These were
      updated.
      
      The changes to the configure script *should* be validated by the build
      bots for the other platforms before landing
      
      Reviewers: simonmar, awson, bgamari, austin, thomie
      
      Reviewed By: thomie
      
      Subscribers: #ghc_windows_task_force, thomie, awson
      
      Differential Revision: https://phabricator.haskell.org/D1123
      
      GHC Trac Issues: #10726, #9014, #9218, #10435
      7b211b4e
  2. 30 Jun, 2015 1 commit
  3. 23 Jun, 2015 1 commit
    • Sergei Trofimovich's avatar
      powerpc: add basic support for PLT relocations (#10402) · c0847967
      Sergei Trofimovich authored
      Commit a93ab43a
      enabled support for proper PIC relocations from
      assembler.
      
      Commit adds support for relocations of type:
          R_PPC_REL16_HI
          R_PPC_REL16_HA
          R_PPC_REL16_LO
          R_PPC_PLTREL24
      
      They are used only when GHC is built in
          DYNAMIC_GHC_PROGRAMS = NO
      mode.
      
      Verified by running the following test:
      
          // cat a.c
          #include <stdio.h>
      
          void ffi_a_hello (int i) {
              fprintf (stderr, "WEEEEEEEE: i=%d\n", i);
          }
      
          -- cat A.hs
          {-# LANGUAGE ForeignFunctionInterface #-}
          module A where
      
          import Foreign.C
      
          foreign import ccall "ffi_a_hello" a :: CInt -> IO ()
      
          # ghc -fPIC -c a.c -fforce-recomp
          # ghc -fPIC -c A.hs -fforce-recomp
          # ghc --interactive ./a.o A
          ...
          *A> a 42
          WEEEEEEEE: i=42
      See gory details in Trac #10402.
      Signed-off-by: default avatarColin Watson <cjwatson@debian.org>
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Reviewed By: bgamari, austin
      
      Differential Revision: https://phabricator.haskell.org/D996
      
      GHC Trac Issues: #10402
      c0847967
  4. 12 Jun, 2015 1 commit
  5. 08 Jun, 2015 1 commit
    • Simon Marlow's avatar
      Fix for CAF retention when dynamically loading & unloading code · 19ec6a84
      Simon Marlow authored
      In a situaion where we have some statically-linked code and we want to
      load and unload a series of objects, we need the CAFs in the
      statically-linked code to be retained indefinitely, while the CAFs in
      the dynamically-linked code should be GC'd as normal, so that we can
      detect when the code is unloadable.  This was wrong before - we GC'd
      CAFs in the static code, leading to a crash in the rare case where we
      use a CAF, GC it, and then load a new object that uses it again.
      
      I also did some tidy up: RtsConfig now has a field keep_cafs to
      indicate whether we want CAFs to be retained in static code.
      19ec6a84
  6. 07 Apr, 2015 2 commits
  7. 03 Apr, 2015 1 commit
  8. 23 Feb, 2015 1 commit
    • Tamar Christina's avatar
      rts/linker: ignore unknown PE sections · a293925d
      Tamar Christina authored
      Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed.
      
      Test Plan:
      See the file `ghcilinkerbug.zip` in #9907.
      
       1) unzip file content.
       2) open examplecpp.cabal and change base <4.8 to <4.9.
       3) execute cabal file with cabal repl.
      
      Applying the patch makes `cabal repl` in step 3) work.
      
      Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99.
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D671
      
      GHC Trac Issues: #9907, #7103, #10051, #7056, #8546
      a293925d
  9. 13 Jan, 2015 2 commits
  10. 10 Dec, 2014 1 commit
  11. 05 Dec, 2014 2 commits
  12. 02 Dec, 2014 2 commits
    • Simon Peyton Jones's avatar
      Revert "Make the linker API thread-safe" · 4b51194d
      Simon Peyton Jones authored
      This reverts commit b5e8b3b1.
      
      I reverted it because one of these two patches
        9e6e4796 Add purgeObj()
        b5e8b3b1 Make the linker API thread-safe
      
      causes a seg-fault on Windows.  The seg-fault happens immediately
      the linker is invoked, in ghci or in Template Haskell.
      
      I believe that it is the "linker API thread-safe" commit that causes
      the seg-fault; it happens even if the "purgeObj" commit alone is
      reverted.  But since the two patches mess with the same code, to
      revert the "linker API" patch I had revert both.
      4b51194d
    • Simon Peyton Jones's avatar
      Revert "Add purgeObj() to remove the symbol table entries for an object" · 7932b2ad
      Simon Peyton Jones authored
      This reverts commit 9e6e4796.
      
      I reverted it because one of these two patches
        9e6e4796 Add purgeObj()
        b5e8b3b1 Make the linker API thread-safe
      
      causes a seg-fault on Windows.  The seg-fault happens immediately
      the linker is invoked, in ghci or in Template Haskell.
      
      I believe that it is the "linker API thread-safe" commit that causes
      the seg-fault; it happens even if the "purgeObj" commit alone is
      reverted.  But since the two patches mess with the same code, to
      revert the "linker API" patch I had revert both.
      7932b2ad
  13. 30 Nov, 2014 1 commit
    • Peter Trommler's avatar
      Fix obscure problem with using the system linker (#8935) · 383733b9
      Peter Trommler authored
      Summary:
      In a statically linked GHCi symbol `environ` resolves to NULL when
      called from a Haskell script.
      
      When resolving symbols in a Haskell script we need to search the
      executable program and its dependent (DT_NEEDED) shared libraries
      first and then search the loaded libraries.
      
      We want to be able to override functions in loaded libraries later.
      Libraries must be opened with local scope (RTLD_LOCAL) and not global.
      The latter adds all symbols to the executable program's symbols where
      they are then searched in loading order. We want reverse loading order.
      
      When libraries are loaded with local scope the dynamic linker
      cannot use symbols in that library when resolving the dependencies
      in another shared library. This changes the way files compiled to
      object code must be linked into temporary shared libraries. We link
      with the last temporary shared library created so far if it exists.
      Since each temporary shared library is linked to the previous temporary
      shared library the dynamic linker finds the latest definition of a
      symbol by following the dependency chain.
      
      See also Note [RTLD_LOCAL] for a summary of the problem and solution.
      
      Cherry-picked commit 2f8b4c
      
      Changed linker argument ordering
      
      On some ELF systems GNU ld (and others?) default to
      --as-needed and the order of libraries in the link
      matters.
      
      The last temporary shared library, must appear
      before all other libraries. Switching the position
      of extra_ld_inputs and lib_path_objs does that.
      
      Fixes #8935 and #9186
      
      Reviewers: austin, hvr, rwbarton, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D349
      
      GHC Trac Issues: #8935, #9186, #9480
      383733b9
  14. 28 Nov, 2014 2 commits
    • Simon Marlow's avatar
      Add purgeObj() to remove the symbol table entries for an object · 9e6e4796
      Simon Marlow authored
      This allows us to replace an object without actually unloading the old
      object, which is necessary when we know we have references to the old
      object so it can't be completely unloaded.  Using unloadObj() would
      cause the GC (CheckUnload) to repeatedly and fruitlessly try to unload
      the old object.
      9e6e4796
    • Simon Marlow's avatar
      Make the linker API thread-safe · b5e8b3b1
      Simon Marlow authored
      We used to be able to rely on the client to use the API in a
      single-threaded way, but now that the GC calls into the linker to
      unload objects this isn't a safe assumption.
      b5e8b3b1
  15. 12 Nov, 2014 1 commit
  16. 30 Oct, 2014 1 commit
    • gintas's avatar
      Use snwprintf instead of swprintf in rts/Linker.c. · 5ce1266a
      gintas authored
      Summary:
      swprintf has different signatures in mingw32, where it does not include the
      buffer size, and in mingw-w64, where it does. That of course breaks the code
      as mingw-w64 treats the pointer to the format string as a size_t.
      
      snwprintf is available in both environments and is consistent, so use that
      instead.
      
      Reviewers: simonmar, austin
      
      Reviewed By: austin
      
      Subscribers: #ghc_windows_task_force, thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D372
      
      GHC Trac Issues: #9726
      5ce1266a
  17. 29 Oct, 2014 1 commit
  18. 25 Oct, 2014 1 commit
  19. 20 Oct, 2014 3 commits
  20. 12 Oct, 2014 1 commit
  21. 08 Oct, 2014 1 commit
    • Simon Marlow's avatar
      Make the linker more robust to errors · 5300099e
      Simon Marlow authored
      Summary:
      When linking fails because there was a problem with the supplied
      object file, then we should not barf() or exit, we should emit a
      suitable error message and return an error code to the caller.  We
      should also free all memory that might have been allocated during
      linking, and generally not do any damage.  This patch fixes most
      common instances of this problem.
      
      Test Plan: validate
      
      Reviewers: rwbarton, austin, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: simonmar, ezyang, carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D294
      5300099e
  22. 03 Oct, 2014 2 commits
  23. 02 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename _closure to _static_closure, apply naming consistently. · 35672072
      Edward Z. Yang authored
      Summary:
      In preparation for indirecting all references to closures,
      we rename _closure to _static_closure to ensure any old code
      will get an undefined symbol error.  In order to reference
      a closure foobar_closure (which is now undefined), you should instead
      use STATIC_CLOSURE(foobar).  For convenience, a number of these
      old identifiers are macro'd.
      
      Across C-- and C (Windows and otherwise), there were differing
      conventions on whether or not foobar_closure or &foobar_closure
      was the address of the closure.  Now, all foobar_closure references
      are addresses, and no & is necessary.
      
      CHARLIKE/INTLIKE were not changed, simply alpha-renamed.
      
      Part of remove HEAP_ALLOCED patch set (#8199)
      
      Depends on D265
      Signed-off-by: Edward Z. Yang's avatarEdward Z. Yang <ezyang@mit.edu>
      
      Test Plan: validate
      
      Reviewers: simonmar, austin
      
      Subscribers: simonmar, ezyang, carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D267
      
      GHC Trac Issues: #8199
      35672072
  24. 29 Sep, 2014 1 commit
  25. 24 Sep, 2014 1 commit
  26. 17 Sep, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement `decodeDouble_Int64#` primop · b62bd5ec
      Herbert Valerio Riedel authored
      The existing `decodeDouble_2Int#` primop is rather inconvenient to use
      (and in fact is not even used by `integer-gmp`) as the mantissa is split
      into 3 components which would actually fit in an `Int64#` value.
      
      However, `decodeDouble_Int64#` is to be used by the new `integer-gmp2`
      re-implementation (see #9281).
      
      Moreover, `decodeDouble_2Int#` performs direct bit-wise operations on the
      IEEE representation which can be replaced by a combination of the
      portable standard C99 `scalbn(3)` and `frexp(3)` functions.
      
      Differential Revision: https://phabricator.haskell.org/D160
      b62bd5ec
  27. 16 Sep, 2014 1 commit
    • AndreasVoellmy's avatar
      Revert "Revert "rts/base: Fix #9423"" and resolve issue that caused the revert. · 7e658bc1
      AndreasVoellmy authored
      Summary:
      This reverts commit 4748f593. The fix for #9423
      was reverted because this commit introduced a C function setIOManagerControlFd()
      (defined in Schedule.c) defined for all OS types, while the prototype
      (in includes/rts/IOManager.h) was only included when mingw32_HOST_OS is
      not defined. This broke Windows builds.
      
      This commit reverts the original commit and resolves the problem by only defining
      setIOManagerControlFd() when mingw32_HOST_OS is defined. Hence the missing prototype
      error should not occur on Windows.
      
      In addition, since the io_manager_control_wr_fd field of the Capability struct is only
      usd by the setIOManagerControlFd, this commit includes the io_manager_control_wr_fd
      field in the Capability struct only when mingw32_HOST_OS is not defined.
      
      Test Plan: Try to compile successfully on all platforms.
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D174
      7e658bc1
  28. 23 Aug, 2014 1 commit
    • Sergei Trofimovich's avatar
      rts/Linker.c: declare 'deRefStablePtr' as an exported 'rts' symbol · 104a66a4
      Sergei Trofimovich authored
          $ inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -optc-fno-builtin -fno-ghci-history \
              testsuite/tests/ffi/should_run/T4038.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS
      
          *Main> main
          <interactive>: /tmp/ghc16668_0/ghc16668_5.o: unknown symbol `deRefStablePtr'
      
      The reference to 'deRefStablePtr' is generated by 'compiler/deSugar/DsForeign.lhs':
          the_cfun
             = case maybe_target of
                Nothing    -> text "(StgClosure*)deRefStablePtr(the_stableptr)"
                Just hs_fn -> char '&' <> ppr hs_fn <> text "_closure"
      
      Patch fixes all broken tests using 'import wrapper':
          TEST="ffi013 ffi010 ffi011 ffi005 ffi020 ffi006 ffi019 fed001 T1679 T4038"
      
      Tests manifested as broken only in DYNAMIC_GHC_PROGRAMS=NO builds,
      where GHCi's custom linker is used instead of system's linker.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      104a66a4
  29. 22 Aug, 2014 1 commit
  30. 20 Aug, 2014 1 commit
  31. 19 Aug, 2014 2 commits
    • AndreasVoellmy's avatar
      rts/base: Fix #9423 · f9f89b78
      AndreasVoellmy authored
      Summary:
      Fix #9423.
      
      The problem in #9423 is caused when code invoked by `hs_exit()` waits
      on all foreign calls to return, but some IO managers are in `safe` foreign
      calls and do not return. The previous design signaled to the timer manager
      (via its control pipe) that it should "die" and when the timer manager
      returned to Haskell-land, the Haskell code in timer manager then signalled
      to the IO manager threads that they should return from foreign calls and
      `die`. Unfortunately, in the shutdown sequence the timer manager is unable
      to return to Haskell-land fast enough and so the code that signals to the
      IO manager threads (via their control pipes) is never executed and the IO
      manager threads remain out in the foreign calls.
      
      This patch solves this problem by having the RTS signal to all the IO
      manager threads (via their control pipes; and in addition to signalling
      to the timer manager thread) that they should shutdown (in `ioManagerDie()`
      in `rts/Signals.c`. To do this, we arrange for each IO manager thread to
      register its control pipe with the RTS (in `GHC.Thread.startIOManagerThread`).
      In addition, `GHC.Thread.startTimerManagerThread` registers its control pipe.
      These are registered via C functions `setTimerManagerControlFd` (in
      `rts/Signals.c`) and `setIOManagerControlFd` (in `rts/Capability.c`). The IO
      manager control pipe file descriptors are stored in a new field of the
      `Capability_ struct`.
      
      Test Plan: See the notes on #9423 to recreate the problem and to verify that it no longer occurs with the fix.
      
      Auditors: simonmar
      
      Reviewers: simonmar, edsko, ezyang, austin
      
      Reviewed By: austin
      
      Subscribers: phaskell, simonmar, ezyang, carter, relrod
      
      Differential Revision: https://phabricator.haskell.org/D129
      
      GHC Trac Issues: #9423, #9284
      f9f89b78
    • Facundo Domínguez's avatar
      Have the RTS linker search symbols in the originating windows binary. · d2f01000
      Facundo Domínguez authored
      Summary: In initLinker, this patch adds the handle of the module corresponding to the program binary to the list of DLL handles that lookupSymbol uses to search for symbols.
      
      Test Plan: validate
      
      Reviewers: simonmar, austin
      
      Reviewed By: simonmar, austin
      
      Subscribers: phaskell, simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D103
      
      GHC Trac Issues: #9382
      d2f01000