1. 07 Nov, 2019 5 commits
  2. 06 Nov, 2019 4 commits
  3. 05 Nov, 2019 7 commits
  4. 04 Nov, 2019 3 commits
    • Ben Gamari's avatar
      rts/linker: Ensure that code isn't writable · 120f2e53
      Ben Gamari authored and  Marge Bot's avatar Marge Bot committed
      For many years the linker would simply map all of its memory with
      PROT_READ|PROT_WRITE|PROT_EXEC. However operating systems have been
      becoming increasingly reluctant to accept this practice (e.g. #17353
      and #12657) and for good reason: writable code is ripe for exploitation.
      Consequently mmapForLinker now maps its memory with
      PROT_READ|PROT_WRITE.  After the linker has finished filling/relocating
      the mapping it must then call mmapForLinkerMarkExecutable on the
      sections of the mapping which contain executable code.
      Moreover, to make all of this possible it was necessary to redesign the
      m32 allocator. First, we gave (in an earlier commit) each ObjectCode its
      own m32_allocator. This was necessary since code loading and symbol
      resolution/relocation are currently interleaved, meaning that it is not
      possible to enforce W^X when symbols from different objects reside in
      the same page.
      We then redesigned the m32 allocator to take advantage of the fact that
      all of the pages allocated with the allocator die at the same time
      (namely, when the owning ObjectCode is unloaded). This makes a number of
      things simpler (e.g. no more page reference counting; the interface
      provided by the allocator for freeing is simpler). See
      Note [M32 Allocator] for details.
    • Leif Metcalf's avatar
      Rephrase note on full-laziness · 5d4f16ee
      Leif Metcalf authored and  Marge Bot's avatar Marge Bot committed
    • Ben Gamari's avatar
      SysTools: Only apply Windows-specific workaround on Windows · 3b65655c
      Ben Gamari authored and  Marge Bot's avatar Marge Bot committed
      Issue #1110 was apparently due to a bug in Vista which prevented GCC
      from finding its binaries unless we explicitly added it to PATH.
      However, this workaround was incorrectly applied on non-Windows
      platforms as well, resulting in ill-formed PATHs (#17266).
      Fixes #17266.
  5. 03 Nov, 2019 2 commits
    • Richard Eisenberg's avatar
      Update Note references -- comments only · 3c916162
      Richard Eisenberg authored and  Marge Bot's avatar Marge Bot committed
      Follow-on from !2041.
    • Sebastian Graf's avatar
      Separate `LPat` from `Pat` on the type-level · 182b1199
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      Since the Trees That Grow effort started, we had `type LPat = Pat`.
      This is so that `SrcLoc`s would only be annotated in GHC's AST, which is
      the reason why all GHC passes use the extension constructor `XPat` to
      attach source locations. See #15495 for the design discussion behind
      But now suddenly there are `XPat`s everywhere!
      There are several functions which dont't cope with `XPat`s by either
      crashing (`hsPatType`) or simply returning incorrect results
      This issue was raised in #17330. I also came up with a rather clean and
      type-safe solution to the problem: We define
      type family XRec p (f :: * -> *) = r | r -> p f
      type instance XRec (GhcPass p) f = Located (f (GhcPass p))
      type instance XRec TH          f =          f p
      type LPat p = XRec p Pat
      This is a rather modular embedding of the old "ping-pong" style, while
      we only pay for the `Located` wrapper within GHC. No ping-ponging in
      a potential Template Haskell AST, for example. Yet, we miss no case
      where we should've handled a `SrcLoc`: `hsPatType` and
      `collectEvVarsPat` are not callable at an `LPat`.
      Also, this gets rid of one indirection in `Located` variants:
      Previously, we'd have to go through `XPat` and `Located` to get from
      `LPat` to the wrapped `Pat`. Now it's just `Located` again.
      Thus we fix #17330.
  6. 02 Nov, 2019 3 commits
  7. 01 Nov, 2019 15 commits
  8. 31 Oct, 2019 1 commit