1. 16 Nov, 2020 1 commit
  2. 15 Nov, 2020 3 commits
    • Matthias Andreas Benkard's avatar
      Document loadFramework changes. (#18446) · e156ae01
      Matthias Andreas Benkard authored
      Adds commentary on the rationale for the changes made in merge request
    • Matthias Andreas Benkard's avatar
      loadFramework: Output the errors collected in all loading attempts. · 70ccc8fd
      Matthias Andreas Benkard authored
      With the recent change away from first finding and then loading a
      framework, loadFramework had no way of communicating the real reason
      why loadDLL failed if it was any reason other than the framework
      missing from the file system.  It now collects all loading attempt
      errors into a list and concatenates them into a string to return to
      the caller.
    • Matthias Andreas Benkard's avatar
      macOS: Load frameworks without stating them first. · f0a38f69
      Matthias Andreas Benkard authored
      macOS Big Sur makes the following change to how frameworks are shipped
      with the OS:
      > New in macOS Big Sur 11 beta, the system ships with a built-in
      > dynamic linker cache of all system-provided libraries. As part of
      > this change, copies of dynamic libraries are no longer present on
      > the filesystem. Code that attempts to check for dynamic library
      > presence by looking for a file at a path or enumerating a directory
      > will fail. Instead, check for library presence by attempting to
      > dlopen() the path, which will correctly check for the library in the
      > cache. (62986286)
      Therefore, the previous method of checking whether a library exists
      before attempting to load it makes GHC.Runtime.Linker.loadFramework
      fail to find frameworks installed at /System/Library/Frameworks.
      GHC.Runtime.Linker.loadFramework now opportunistically loads the
      framework libraries without checking for their existence first,
      failing only if all attempts to load a given framework from any of the
      various possible locations fail.
  3. 14 Nov, 2020 1 commit
    • Ben Gamari's avatar
      rts/linker: Fix relocation overflow in PE linker · c58498b2
      Ben Gamari authored
      Previously the overflow check for the IMAGE_REL_AMD64_ADDR32NB
      relocation failed to account for the signed nature of the value.
      Specifically, the overflow check was:
          uint64_t v;
          v = S + A;
          if (v >> 32) { ... }
      However, `v` ultimately needs to fit into 32-bits as a signed value.
      Consequently, values `v > 2^31` in fact overflow yet this is not caught
      by the existing overflow check.
      Here we rewrite the overflow check to rather ensure that
      `INT32_MIN <= v <= INT32_MAX`. There is now quite a bit of repetition
      between the `IMAGE_REL_AMD64_REL32` and `IMAGE_REL_AMD64_ADDR32` cases
      but I am leaving fixing this for future work.
      This bug was first noticed by @awson.
      Fixes #15808.
      (cherry picked from commit 6d21ecee)
  4. 19 Oct, 2020 1 commit
  5. 08 Oct, 2020 1 commit
  6. 29 Sep, 2020 1 commit
    • Ömer Sinan Ağacan's avatar
      Fix uninitialized field read in Linker.c · 16f83b57
      Ömer Sinan Ağacan authored
      Valgrind report of the bug when running the test `linker_unload`:
          ==29666== Conditional jump or move depends on uninitialised value(s)
          ==29666==    at 0x369C5B4: setOcInitialStatus (Linker.c:1305)
          ==29666==    by 0x369C6C5: mkOc (Linker.c:1347)
          ==29666==    by 0x36C027A: loadArchive_ (LoadArchive.c:522)
          ==29666==    by 0x36C0600: loadArchive (LoadArchive.c:626)
          ==29666==    by 0x2C144CD: ??? (in /home/omer/haskell/ghc_2/testsuite/tests/rts/linker/linker_unload.run/linker_unload)
          ==29666== Conditional jump or move depends on uninitialised value(s)
          ==29666==    at 0x369C5B4: setOcInitialStatus (Linker.c:1305)
          ==29666==    by 0x369C6C5: mkOc (Linker.c:1347)
          ==29666==    by 0x369C9F6: preloadObjectFile (Linker.c:1507)
          ==29666==    by 0x369CA8D: loadObj_ (Linker.c:1536)
          ==29666==    by 0x369CB17: loadObj (Linker.c:1557)
          ==29666==    by 0x3866BC: main (linker_unload.c:33)
      The problem is `mkOc` allocates a new `ObjectCode` and calls
      `setOcInitialStatus` without initializing the `status` field.
      `setOcInitialStatus` reads the field as first thing:
          static void setOcInitialStatus(ObjectCode* oc) {
              if (oc->status == OBJECT_DONT_RESOLVE)
              if (oc->archiveMemberName == NULL) {
                  oc->status = OBJECT_NEEDED;
              } else {
                  oc->status = OBJECT_LOADED;
      `setOcInitialStatus` is unsed in two places for two different purposes:
      in `mkOc` where we don't have the `status` field initialized yet (`mkOc`
      is supposed to initialize it), and `loadOc` where we do have `status`
      field initialized and we want to update it. Instead of splitting the
      function into two functions which are both called just once I inline the
      functions in the use sites and remove it.
      Fixes #18342
      (cherry picked from commit 08c1cb0f)
  7. 11 Sep, 2020 1 commit
    • Moritz Angermann's avatar
      [macOS] improved runpath handling · 3ebc51e6
      Moritz Angermann authored
      In b592bd98 we started using
      -dead_strip_dylib on macOS when lining dynamic libraries and binaries.
      The underlying reason being the Load Command Size Limit in macOS
      Sierra (10.14) and later.
      GHC will produce @rpath/libHS... dependency entries together with a
      corresponding RPATH entry pointing to the location of the libHS...
      library. Thus for every library we produce two Load Commands.  One to
      specify the dependent library, and one with the path where to find it.
      This makes relocating libraries and binaries easier, as we just need to
      update the RPATH entry with the install_name_tool. The dynamic linker
      will then subsitute each @rpath with the RPATH entries it finds in the
      libraries load commands or the environement, when looking up @rpath
      relative libraries.
      -dead_strip_dylibs intructs the linker to drop unused libraries. This in
      turn help us reduce the number of referenced libraries, and subsequently
      the size of the load commands.  This however does not remove the RPATH
      entries.  Subsequently we can end up (in extreme cases) with only a
      single @rpath/libHS... entry, but 100s or more RPATH entries in the Load
      This patch rectifies this (slighly unorthodox) by passing *no* -rpath
      arguments to the linker at link time, but -headerpad 8000.  The
      headerpad argument is in hexadecimal and the maxium 32k of the load
      command size.  This tells the linker to pad the load command section
      enough for us to inject the RPATHs later.  We then proceed to link the
      library or binary with -dead_strip_dylibs, and *after* the linking
      inspect the library to find the left over (non-dead-stripped)
      dependencies (using otool).  We find the corresponding RPATHs for each
      @rpath relative dependency, and inject them into the library or binary
      using the install_name_tool.  Thus achieving a deadstripped dylib (and
      rpaths) build product.
      We can not do this in GHC, without starting to reimplement a dynamic
      linker as we do not know which symbols and subsequently libraries are
      Commissioned-by: Mercury Technologies, Inc. (mercury.com)
      (cherry picked from commit 4ff93292)
      Signed-off-by: default avatarMoritz Angermann <moritz.angermann@iohk.io>
  8. 29 Aug, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Import qualified Prelude in Cmm/Parser.y · d6cbfd9a
      Krzysztof Gogolewski authored
      In preparation for the next version of 'happy', c95920 added a qualified
      import to GHC/Parser.y but for some reason neglected GHC/Cmm/Parser.y
      This patch adds the missing qualified import to GHC/Cmm/Parser.y and
      also adds a clarifying comment to explain why this import is needed.
      (cherry picked from commit fddddbf4)
  9. 22 Jul, 2020 1 commit
  10. 14 Jul, 2020 2 commits
  11. 13 Jul, 2020 1 commit
  12. 12 Jul, 2020 1 commit
  13. 08 Jul, 2020 12 commits
  14. 06 Jul, 2020 1 commit
  15. 04 Jul, 2020 3 commits
  16. 24 Jun, 2020 3 commits
  17. 23 Jun, 2020 1 commit
  18. 21 Jun, 2020 1 commit
  19. 20 Jun, 2020 2 commits
  20. 31 May, 2020 1 commit
  21. 30 May, 2020 1 commit
    • Ömer Sinan Ağacan's avatar
      FastString: fix eager reading of string ptr in hashStr · bc05d359
      Ömer Sinan Ağacan authored
      This read causes NULL dereferencing when len is 0.
      Fixes #17909
      In the reproducer in #17909 this bug is triggered as follows:
      - SimplOpt.dealWithStringLiteral is called with a single-char string
        ("=" in #17909)
      - tailFS gets called on the FastString of the single-char string.
      - tailFS checks the length of the string, which is 1, and calls
        mkFastStringByteString on the tail of the ByteString, which is an
        empty ByteString as the original ByteString has only one char.
      - ByteString's unsafeUseAsCStringLen returns (NULL, 0) for the empty
        ByteString, which is passed to mkFastStringWith.
      - mkFastStringWith gets hash of the NULL pointer via hashStr, which
        fails on empty strings because of this bug.
      (cherry picked from commit cb1785d9)