1. 03 Jan, 2016 4 commits
  2. 30 Dec, 2015 1 commit
  3. 27 Dec, 2015 5 commits
  4. 22 Dec, 2015 1 commit
    • Tamar Christina's avatar
      Fix GHCi segfault in Windows 32bit · aa7fb9a6
      Tamar Christina authored
      Summary:
      Add missing calling convention to function pointer,
      incorrect `cdecl` calling convention which should be `stdcall`
      on x86 was causing the stack to be corrupted. When it tried to
      return from the function the return pointer would be invalid.
      
      Test Plan: ./validate
      
      Reviewers: austin, erikd, bgamari, thomie
      
      Reviewed By: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1683
      
      GHC Trac Issues: #11234
      aa7fb9a6
  5. 07 Dec, 2015 1 commit
  6. 04 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Use Autoconf's AC_USE_SYSTEM_EXTENSIONS · 7af29da0
      Herbert Valerio Riedel authored
      This takes care of setting feature test macros (i.e. let Autoconf decide when
      those can be set safely) to allow subsequent Autoconf tests to better detect
      available OS features.
      
      This also includes a submodule update of unix which enables the use of
      `AC_USE_SYSTEM_EXTENSIONS` in there as well.
      
      Specifically, this takes care of setting `_GNU_SOURCE` (which allows to remove
      two occurences where it's set manually) and `_ALL_SOURCE` (which fixes issues
      on AIX).
      
      See also
      
        https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Posix-Variants.html
      
      for details.
      
      At some point we may want to reconsider the purpose of "rts/PosixSource.h" and
      rely more on Autoconf instead.
      7af29da0
  7. 17 Nov, 2015 1 commit
    • Tamar Christina's avatar
      Fix archive loading on Windows by the runtime loader · acce37f3
      Tamar Christina authored
      The runtime loader is unable to find archive files `.a` shipping
      with the inplace `GCC`.
      
      It seems the issue is caused by `findArchive` being unable to
      find any archives that are shipped using the in-place `GCC`.
      
      - It works on Linux because `findArchive` would search
        the standard Linux include path.
      - It works during compilation because `GCC` can find it's own libraries
        (we explicitly tell it where to look for libraries using the `gcc`
        wrapper around `realgcc`)
      
      So fixing the issue means using `searchForLibUsingGcc` in `findArchive`
      as well, which will then find the correct file.
      
      The reason for the error as it is, is because if we can't locate the
      library using any of the methods we have, we assume it is a system dll,
      or something on the system search path.  e.g. if trying to load
      `kernel32.dll`.
      
      There is a slight issue in that the `GHCi` code (incorrectly) favors
      `static archives` over `dynamic` ones
      
      ```
      findDll        `orElse`
      findArchive    `orElse`
      tryGcc         `orElse`
      tryGccPrefixed `orElse`
      assumeDll
      ```
      This has the unwanted effect of when `kernel32` is specified as a lib,
      it will try to load `kernel32.a` instead of `kernel32.dll`.
      
      To solve this I have added another search function that is able to
      search the Windows search paths using `SearchPath` in order to find if
      it is a dll on the system search path.
      
      The new search order is:
      
      ```
      findDll     `orElse`
      findSysDll  `orElse`
      tryGcc      `orElse`
      findArchive `orElse`
      assumeDll
      ```
      
      (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at
      top level)
      
      Test Plan: ./validate added new windows tests T3242
      
      Reviewers: thomie, erikd, hvr, austin, bgamari
      
      Reviewed By: thomie, erikd, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1455
      
      GHC Trac Issues: #3242
      acce37f3
  8. 11 Nov, 2015 1 commit
    • kgardas's avatar
      fix RTS Linker on platforms without SHN_XINDEX support · 9bea234d
      kgardas authored
      Summary:
      This patch fixes RTS Linker compilation issues on platforms
      where SHN_XINDEX is not defined. Tested on OpenBSD. When SHN_XINDEX
      is not defined, the code reverts to the old behavior, that means
      behavior of the Linker before D1357 which added SHN_XINDEX based
      functionality.
      
      Reviewers: bgamari, austin, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1446
      9bea234d
  9. 07 Nov, 2015 2 commits
    • 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
    • Simon Marlow's avatar
      Make GHCi & TH work when the compiler is built with -prof · ce1f1607
      Simon Marlow authored
      Summary:
      Amazingly, there were zero changes to the byte code generator and very
      few changes to the interpreter - mainly because we've used good
      abstractions that hide the differences between profiling and
      non-profiling.  So that bit was pleasantly straightforward, but there
      were a pile of other wibbles to get the whole test suite through.
      
      Note that a compiler built with -prof is now like one built with
      -dynamic, in that to use TH you have to build the code the same way.
      For dynamic, we automatically enable -dynamic-too when TH is required,
      but we don't have anything equivalent for profiling, so you have to
      explicitly use -prof when building code that uses TH with a profiled
      compiler.  For this reason Cabal won't work with TH.  We don't expect
      to ship a profiled compiler, so I think that's OK.
      
      Test Plan: validate with GhcProfiled=YES in validate.mk
      
      Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1407
      
      GHC Trac Issues: #4837, #545
      ce1f1607
  10. 04 Nov, 2015 1 commit
  11. 02 Nov, 2015 1 commit
    • kgardas's avatar
      get rid of Elf32/Elf64_Section as this is a non-portable Linux-ism. · c00c5e5b
      kgardas authored
      Summary:
      D1357 introduces usage of Elf32_Section/Elf64_Section in RTS linker
      code. Unfortunately this is a non-portable Linux-ism and such types are not
      defined anywhere except the Linux-land probably. I've checked Solaris 11.2,
      Solaris 11.3, FreeBSD 10.1, NetBSD 6.1.5 and OpenBSD current. The fix
      is easy to use `unsigned short' as this is also an underlying type
      of those Elf*_Section defines in Linux.
      
      Reviewers: olsner, austin, bgamari, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1419
      c00c5e5b
  12. 01 Nov, 2015 2 commits
  13. 30 Oct, 2015 2 commits
    • Erik de Castro Lopo's avatar
      Linker: Clean up USE_MMAP usage · 3e2c227e
      Erik de Castro Lopo authored
      Test Plan: Validate on powerpc/linux, x86_64/linux and x86_64/darwin
      
      Reviewers: austin, bgamari, thomie
      
      Reviewed By: thomie
      
      Subscribers: Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1398
      3e2c227e
    • Erik de Castro Lopo's avatar
      Linker: Fix type in m32_free_internal · 8ddf4174
      Erik de Castro Lopo authored
      The code:
      
          uint64_t c = __sync_sub_and_fetch((uint64_t*)addr, 1);
      
      was causing GCC to emit atomic instructions for 64 bit values which
      are not available on PowerPC. However, since PowerPC only has a 32
      bit address space, use of a 64 bit value is superflous.
      
      Switching the type from `uint64_t` to `uintptr_t` should simply do
      the correct thing on all 32 and 64 bit architectures.
      
      Reviewers: austin, bgamari, simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1399
      
      GHC Trac Issues: #11036
      8ddf4174
  14. 29 Oct, 2015 1 commit
  15. 26 Oct, 2015 1 commit
  16. 25 Oct, 2015 1 commit
  17. 24 Oct, 2015 1 commit
  18. 21 Oct, 2015 1 commit
  19. 18 Oct, 2015 1 commit
  20. 17 Oct, 2015 1 commit
  21. 16 Oct, 2015 2 commits
  22. 15 Oct, 2015 1 commit
    • Simon Marlow's avatar
      ELF/x86_64: map object file sections separately into the low 2GB · 04e83666
      Simon Marlow authored
      On 64-bit ELF we need to link object files into the low 2GB due to the
      small memory model.  Previously we would map the entire object file
      using MAP_32BIT, but the object file can consist of 75% or more
      symbols, which only need to be present during linking, so this is
      wasteful.  In our particular application, we're already running out of
      space here.
      
      This patch changes the way we load object files on ELF platforms so
      that the object is first mapped above the 2GB boundary, parsed, and
      then the important sections are re-mapped into the low 2GB area.
      
      Test Plan:
      validate
      (also needs testing on OS X & Windows, preferably 32 & 64 bit)
      
      Reviewers: Phyx, trommler, bgamari, austin
      
      Subscribers: hsyl20, thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D975
      04e83666
  23. 14 Oct, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Fix GHCi on Arm (#10375). · 933adc0f
      Erik de Castro Lopo authored
      Arm has two instruction sets, Arm and Thumb, and an execution mode for each.
      Executing Arm code in Thumb mode or vice-versa will likely result in an
      Illegal instruction exception.
      
      Furthermore, Haskell code compiled via LLVM was generating Arm instructions
      while C code compiled via GCC was generating Thumb code by default. When
      these two object code types were being linked by the system linker, all was
      fine, because the system linker knows how to jump and call from one
      instruction set to the other.
      
      The first problem was with GHCi's object code loader which did not know
      about Thumb vs Arm. When loading an object file `StgCRun` would jump
      into the loaded object which could change the mode causing a crash after
      it returned. This was fixed by forcing all C code to generate Arm
      instructions by passing `-marm` to GCC.
      
      The second problem was the `mkJumpToAddr` function which was generating
      Thumb instructions. Changing that to generate Arm instructions instead
      results in a working GHCi on Arm.
      
      Test Plan: validate on x86_64 and arm
      
      Reviewers: bgamari, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1323
      
      GHC Trac Issues: #10375
      933adc0f
  24. 03 Oct, 2015 1 commit
    • Tamar Christina's avatar
      Make Windows linker more robust to unknown sections · 620fc6f9
      Tamar Christina authored
      The Windows Linker has 3 main parts that this patch changes.
      
      1) Identification and classification of sections
      2) Adding of symbols to the symbols tables
      3) Reallocation of sections
      
      1.
      Previously section identification used to be done on a whitelisted
      basis. It was also exclusively being done based on the names of the
      sections. This meant that there was a bit of a cat and mouse game
      between `GCC` and `GHC`. Every time `GCC` added new sections there was a
      good chance `GHC` would break. Luckily this hasn't happened much in the
      past because the `GCC` versions `GHC` used were largely unchanged.
      
      The new code instead treats all new section as `CODE` or `DATA`
      sections, and changes the classifications based on the `Characteristics`
      flag in the PE header. By doing so we no longer have the fragility of
      changing section names. The one exception to this is the `.ctors`
      section, which has no differentiating flag in the PE header, but we know
      we need to treat it as initialization data.
      
      The check to see if the sections are aligned by `4` has been removed.
      The reason is that debug sections often time are `1 aligned` but do have
      relocation symbols. In order to support relocations of `.debug` sections
      this check needs to be gone. Crucially this assumption doesn't seem to
      be in the rest of the code. We only check if there are at least 4 bytes
      to realign further down the road.
      
      2.
      The second loop is iterating of all the symbols in the file and trying
      to add them to the symbols table. Because the classification of the
      sections we did previously are (currently) not available in this phase
      we still have to exclude the sections by hand. If they don't we will
      load in symbols from sections we've explicitly ignored the in # 1. This
      whole part should rewritten to avoid this. But didn't want to do it in
      this commit.
      
      3.
      Finally the sections are relocated. But for some reason the PE files
      contain a Linux relocation constant in them `0x0011` This constant as
      far as I can tell does not come from GHC (or I couldn't find where it's
      being set). I believe this is probably a bug in GAS. But because the
      constant is in the output we have to handle it. I am thus mapping it to
      the constant I think it should be `0x0003`.
      
      Finally, static linking *should* work, but won't. At least not if you
      want to statically link `libgcc` with exceptions support. Doing so would
      require you to link `libgcc` and `libstd++` but also `libmingwex`. The
      problem is that `libmingwex` also defines a lot of symbols that the RTS
      automatically injects into the symbol table. Presumably because they're
      symbols that it needs. like `coshf`. The these symbols are not in a
      section that is declared with weak symbols support. So if we ever want
      to get this working, we should either a) Ask mingw to declare the
      section as such, or b) treat all a imported symbols as being weak.
      Though this doesn't seem like it's a good idea..
      
      Test Plan:
      Running ./validate for both x86 and x86_64
      
      Also running the specific test case for #10672
      
      make TESTS="T10672_x86 T10672_x64"
      
      Reviewed By: ezyang, thomie, austin
      
      Differential Revision: https://phabricator.haskell.org/D1244
      
      GHC Trac Issues: #9907, #10672, #10563
      620fc6f9
  25. 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
  26. 30 Jun, 2015 1 commit
  27. 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
  28. 12 Jun, 2015 1 commit
  29. 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