| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Zero size sections are common even during regular build on MacOS. For
instance:
```
$ ar -xv libHSghc-prim-0.6.1.a longlong.o
$ otool -l longlong.o
longlong.o:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
0xfeedfacf 16777223 3 0x00 1 2 176 0x00002000
Load command 0
cmd LC_SEGMENT_64
cmdsize 152
segname
vmaddr 0x0000000000000000
vmsize 0x0000000000000000 <-- segment size = 0
fileoff 208
filesize 0
maxprot 0x00000007
initprot 0x00000007
nsects 1
flags 0x0
Section
sectname __text
segname __TEXT
addr 0x0000000000000000
size 0x0000000000000000 <-- section size = 0
offset 208
align 2^0 (1)
reloff 0
nreloc 0
flags 0x80000000
reserved1 0
reserved2 0
cmd LC_BUILD_VERSION
cmdsize 24
platform macos
sdk 10.14
minos 10.14
ntools 0
```
The issue of `mmap`ing 0 bytes was resolved in !1050, but the problem
remained. These 0 size segments and sections were still allocated in
object code, which lead to failed `ASSERT(size > 0)` in
`addProddableBlock` further down the road.
With this change zero size segments **and** sections are not
mapped/allocated at all.
Test plan:
1. Build statically linked GHC.
2. Run `ghc --interactive`. Observe that REPL loads
successfully (which was not the case before).
3. Load several more compiled hs files into repl. No failures.
|
|
|
|
|
|
|
|
| |
The old test was wrong at least for gcc and the value -2287728808L.
It also relied on implementation defined behaviour (right shift
on a negative value), which might or might not be ok.
Either way it's now a simple comparison which will always work.
|
|
|
|
|
|
|
|
| |
These are unexploded minds as far as the linter is concerned. I don't
want to hit in my MRs by mistake!
I did this with `sed`, and then rolled back some changes in the docs,
config.guess, and the linter itself.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This adds lookup logic for _GLOBAL_OFFSET_TABLE_ as well as
relocation logic for R_ARM_BASE_PREL and R_ARM_GOT_BREL which
the gnu toolchain (gas, gcc, ...) prefers to produce. Apparently
recent llvm toolchains will produce those as well.
|
|
|
|
|
|
|
| |
`checkUnload` currently doesn't check the info header of static objects.
Thus, it may free an `ObjectCode` struct wrongly even if there's still a
live static object whose info header lies in a mapped section of that
`ObjectCode`. This fixes the issue by adding an appropriate check.
|
|
|
|
|
|
|
|
| |
This fixes a regression, introduced by 67c422ca, where we mprotect'd the
global offset table (GOT) region to PROT_READ before we had finished
filling it, resulting in a linker crash.
Fixes #16779.
|
| |
|
|
|
|
|
|
|
| |
The PLT needs to be located within a close distance of
the code calling it under the small memory model.
Fixes #16784.
|
| |
|
|
|
|
|
|
|
| |
As noted in #16701, it is possible that we will find that an object has
no segments needing to be mapped. Previously this would result in mmap
being called for a zero-length mapping, which would fail. We now simply
skip the mmap call in this case; the rest of the logic just works.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Place each section on a separate page to ensure required
alignment (wastes lots ot space, needs to be improved).
2. Unwire relocation logic from macho sections (the most fiddly part
is adjusting internal relocations).
Other todos:
0. Add a test for section alignment.
1. Investigate 32bit relocations!
2. Fix memory leak in ZEROPAGE section allocation.
3. Fix creating redundant jump islands for GOT.
4. Investigate more compact section placement.
|
|
|
|
|
| |
This moves all URL references to Trac tickets to their corresponding
GitLab counterparts.
|
|
|
|
|
|
| |
Some code is broken, there are no CI targets (so not obvious how to
test), and no one seems to have built GHC for any of the above
platforms in years.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When `+RTS -xp` is passed, when don't need the X86_64_ELF_NONPIC_HACK,
becasue the relocation offset should only be out of range if
* the object file was not compiled with `-fPIC -fexternal-dynamic-refs`;
* ghc generates non-pic code while it should (e.g. #15723)
In either case, we should print an error message rather that silently
attempt to use a hacky workaround that may not work.
This could have made debugging #15723 and #15729 much easier.
Test Plan:
Run this in a case where ghci used to crash becasue of T15723. Now we
see helpful message like:
```
ghc-iserv-prof: R_X86_64_PC32 relocation out of range:
stmzm2zi4zi4zi1zmJQn4hNPyYjP5m9AcbI88Ve_ControlziConcurrentziSTMziTMVar_readTMVar_C61n_cc
= 9b95ffac
```
Reviewers: simonmar, bgamari, erikd
Reviewed By: simonmar, bgamari
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5233
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This re-applies {D5195} and {D5235}, they were reverted as part of diff
stack to unbreak i386. The proper fix is done in {D5289}.
Allocate bss section within proper range of other sections:
* when `+RTS -xp` is passed, allocate it contiguously as we did for
jump islands
* when we mmap the code to lower 2Gb, we should allocate bss section
there too
Test Plan:
1. `./validate`
2.
with
```
DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT = NO
```
`TEST="T15729" make test` passed in both linux (both i386 and x86_64) and macos.
3.
Also test in a use case where we used to encouter error like:
```
ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) =
b90282ba
```
and now, everything works fine.
Reviewers: simonmar, bgamari, angerman, erikd
Reviewed By: simonmar
Subscribers: rwbarton, carter
GHC Trac Issues: #15729
Differential Revision: https://phabricator.haskell.org/D5290
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This re-applies {D5195} with fixes for i386:
* Fix unused label warnings, see {D5230} or {D5273}
* Fix a silly bug introduced by moving `#if`
{P190}
Add a RTS option -xp to load PIC object anywhere in address space. We do
this by relaxing the requirement of <0x80000000 result of
`mmapForLinker` and implying USE_CONTIGUOUS_MMAP.
We also need to change calls to `ocInit` and `ocGetNames` to avoid
dangling pointers when the address of `oc->image` is changed by
`ocAllocateSymbolExtra`.
Test Plan:
See {D5195}, also test under i386:
```
$ uname -a
Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28
20:45:30 CEST 2018 i686 GNU/Linux
$ cd testsuite/tests/th/ && make test
...
```
will run `./validate` on stacked diff.
Reviewers: simonmar, bgamari, alpmestan, trommler, hvr, erikd
Reviewed By: simonmar
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5289
|
|
|
|
| |
This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
|
| |
|
|
|
|
|
|
|
| |
Support for Mac OS X on PowerPC has been dropped by Apple years ago. We
follow suit and remove PowerPC support for Darwin.
Fixes #16106.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes a corner case in which we have seen the symbol multiple times in
different static libraries, but due to a depencency we end up loading the
symbol from a library other than the first one.
Previously the runtime linker would only track symbols from the first
library and did not store the full link map. In this case it was unable
to find the address for the symbols in the second library during delay
loading.
This change stores the address of all symbols seen so a full link map
is generated, such that when we make a different decision later than what
was expected we're able to still correctly load the library.
Test Plan: ./validate, new testcase T15894
Reviewers: angerman, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15894
Differential Revision: https://phabricator.haskell.org/D5353
|
|
|
|
| |
Fixes #15105
|
|
|
|
| |
Eliminates a bit of repetition.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes BSS initialization such that it is
initialized to 0 as you'd expect.
Test Plan: ./validate, test T7040_ghci
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15669
Differential Revision: https://phabricator.haskell.org/D5364
|
|
|
|
| |
Previously we should just blinding dereference a NULL pointer.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using the GCC `/* fallthrough */` syntax we now use the
`__attribute__((fallthrough))`, which Phyx says should be more portable
than the former.
Also adds a missing fallthrough annotation in the MachO linker,
fixing #14613.
Reviewers: erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, carter
GHC Trac Issues: #14613
Differential Revision: https://phabricator.haskell.org/D5292
|
|
|
|
| |
This reverts commit 5403a8636fe82f971234873564f3a05393b89b7a.
|
|
|
|
|
|
|
|
| |
This reverts commit e019ec94f12268dd92ea5d5204e9e57e7ebf10ca.
This sadly breaks the external interpreter on i386.
For instance, see https://circleci.com/gh/ghc/ghc/10925.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allocate bss section within proper range of other sections:
* when `+RTS -xp` is passed, allocate it contiguously as we did for
jump islands
* when we mmap the code to lower 2Gb, we should allocate bss section
there too
This depends on {D5195}
Test Plan:
1. `./validate`
2.
with
```
DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT = NO
```
`TEST="T15729" make test` passed in both linux and macos.
3.
Also test in a use case where we used to encouter error like:
```
ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) =
b90282ba
```
and now, everything works fine.
Reviewers: simonmar, bgamari, angerman, erikd
Reviewed By: simonmar
Subscribers: rwbarton, carter
GHC Trac Issues: #15729
Differential Revision: https://phabricator.haskell.org/D5219
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a RTS option -xp to load PIC object anywhere in address space. We do
this by relaxing the requirement of <0x80000000 result of
`mmapForLinker` and implying USE_CONTIGUOUS_MMAP.
We also need to change calls to `ocInit` and `ocGetNames` to avoid
dangling pointers when the address of `oc->image` is changed by
`ocAllocateSymbolExtra`.
Test Plan:
```
$ uname -a
Linux localhost 4.18.8-arch1-1-ARCH #1 SMP PREEMPT Sat Sep 15 20:34:48
UTC 2018 x86_64 GNU/Linux
$ cat mk/build.mk
DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT = NO
GhcRTSWays += thr_debug
EXTRA_HC_OPTS += -debug
WAY_p_HC_OPTS += -fPIC -fexternal-dynamic-refs
$ inplace/bin/ghc-stage2 --interactive -prof +RTS -xp
GHCi, version 8.7.20180928: http://www.haskell.org/ghc/ :? for help
ghc-stage2: R_X86_64_32 relocation out of range:
ghczmprim_GHCziTypes_ZMZN_closure = 7f690bffab59
Recompile
/data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim
-0.5.3.o with -fPIC -fexternal-dynamic-refs.
ghc-stage2: unable to load package `ghc-prim-0.5.3'
$ strace -f -e open,mmap inplace/bin/ghc-stage2 --interactive -prof
-fexternal-interpreter -opti+RTS -opti-xp
...
[pid 1355283]
open("/data/users/watashi/ghc/libraries/base/dist-install/build/libHSbas
e-4.12.0.0_p.a", O_RDONLY) = 14
[pid 1355283] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a84842000
[pid 1355283]
open("/data/users/watashi/ghc/libraries/base/dist-install/build/libHSbas
e-4.12.0.0_p.a", O_RDONLY) = 14
[pid 1355283] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a84676000
...
Prelude> System.Posix.Process.getProcessID
...
[pid 1355283]
open("/data/users/watashi/ghc/libraries/unix/dist-install/build/libHSuni
x-2.7.2.2_p.a", O_RDONLY) = 14
[pid 1355283] mmap(NULL, 45056, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a67d60000
[pid 1355283]
open("/data/users/watashi/ghc/libraries/unix/dist-install/build/libHSuni
x-2.7.2.2_p.a", O_RDONLY) = 14
[pid 1355283] mmap(NULL, 57344, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a67d52000
...
```
```
$ uname -a
Darwin watashis-iMac.local 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug
22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64
$ mv
/Users/watashi/gao/ghc/libraries/integer-gmp/dist-install/build/HSintege
r-gmp-1.0.2.0.o{,._DISABLE_GHC_ISSUE_15105}
$ inplace/bin/ghc-stage2 --interactive +RTS -xp
GHCi, version 8.7.20181003: http://www.haskell.org/ghc/ :? for help
Prelude> System.Posix.Process.getProcessID
42791
Prelude> Data.Set.fromList [1 .. 10]
fromList [1,2,3,4,5,6,7,8,9,10]
Prelude>
Leaving GHCi.
$ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter
GHCi, version 8.7.20181003: http://www.haskell.org/ghc/ :? for help
Prelude> System.Posix.Process.getProcessID
42806
Prelude> Data.Set.fromList [1 .. 10]
fromList [1,2,3,4,5,6,7,8,9,10]
Prelude>
Leaving GHCi.
```
Also test with something that used to hit the 2Gb limit and it loads
and runs without problem.
Reviewers: simonmar, bgamari, angerman, Phyx, hvr, erikd
Reviewed By: simonmar
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix some various issues that popped up because the linker now doesn't
load import libraries for longer than it needs to.
These are all use after free issues.
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: simonpj, rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Always check that no overflow happens during relocation for x86_64.
It's not safe to assume the result returned by `ocAllocateSymbolExtras` is
always valid if we allocate it neither in lower 2G nor in a contiguous range
with the image.
There are also some minor fixes in this diff:
* `off >= 0x7fffffffL` should be `>`
* use of unaligned pointer is undefined behavior, use `memcpy` instead, gcc
will be able to optimize it to `mov %edx, (%rax)`.
Test Plan:
build ghci with:
```
DYNAMIC_GHC_PROGRAMS = NO
DYNAMIC_BY_DEFAULT = NO
```
and play with it.
./validate
Reviewers: simonmar, austin, bgamari, erikd
Reviewed By: simonmar
Subscribers: alpmestan, rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5168
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is to address a couple of short comings of the PE linker.
The first thing it does is properly honor section alignments, so SSE code
will work reliably.
While doing this I've also changed how it reads and stores ObjectFile
information. Previously the entire object file was read in and treated
as one blob, including headers, symbol tables etc.
Now the ObjectFile is read in but stored in chunks, tables go into a temporary
info struct and code/data into a new private heap. This allows me to free all
meta data once we're done relocating. Which means we can reclaim this memory.
As I've mentioned above I've also moved from using VirtualAlloc to HeapAlloc.
The reason is VirtualAlloc is meant to be used for more low level memory
allocation, it's very fast because it can only allocate whole blocks,
(64k) by default, and the memory must be paged (4k) aligned.
So when you ask for e.g. 30k of memory, you're given a whole block where 34k
will be wasted memory. Nothing else can ever access that untill you free the 30k.
One downside of HeapAlloc is that you're not in control of how the heap grows,
and heap memory is always committed. So it's harder to tell how much we're
actually using now.
Another big upside of splitting off the ObjectCode tables to info structs
is that I can adjust them, so that later addressings can just use array
subscripts to index into them. This simplifies the code a lot and a lot of
complicated casts and indexing can be removed. Leaving less and more simple
code.
This patch doesn't fix the memprotection but it doesn't regress it either.
It does however make the next changes smaller and fixes the alignments.
Test Plan: ./validate , new test T13617
Reviewers: bgamari, erikd, simonmar, hvr, angerman
Reviewed By: angerman
Subscribers: nickkuk, carter, RyanGlScott, rwbarton, thomie
GHC Trac Issues: #13617
Differential Revision: https://phabricator.haskell.org/D3915
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
protect mmaped addresses from writes after being initially manipulated
Test Plan: ./validate
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: angerman, carlostome, rwbarton, thomie, carter
GHC Trac Issues: #14069
Differential Revision: https://phabricator.haskell.org/D4817
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: none
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: thomie, carter
Differential Revision: https://phabricator.haskell.org/D4551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This shims out fopen and sopen so that they use modern APIs under the hood
along with namespaced paths.
This lifts the MAX_PATH restrictions from Haskell programs and makes the new
limit ~32k.
There are only some slight caveats that have been documented.
Some utilities have not been upgraded such as lndir, since all these things are
different cabal packages I have been forced to copy the source in different places
which is less than ideal. But it's the only way to keep sdist working.
Test Plan: ./validate
Reviewers: hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #10822
Differential Revision: https://phabricator.haskell.org/D4416
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The failure is visible when we build a cross-compiler
from linux to mingw32 as:
```
$ ./configure --host=x86_64-pc-linux-gnu \
--target=x86_64-w64-mingw32
$ make
rts/linker/PEi386.c:159:10: error:
fatal error: Psapi.h: No such file or directory
#include <Psapi.h>
^~~~~~~~~
|
159 | #include <Psapi.h>
| ^
```
The problem here is case-sensitive linux filesystem. On windows
it does not matter what case is used for includes and libraries.
mingw32 provides all libraries and headers lowercase. This change
fixes case for <dbghelp.h>, <psapi.h>, -ldbghelp, -lpsapi.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Reviewers: bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4247
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds the ability to generate stack traces on crashes for Windows.
When running in the interpreter this attempts to use symbol information from
the interpreter and information we know about the loaded object files to
resolve addresses to symbols.
When running compiled it doesn't have this information and then defaults
to using symbol information from PDB files. Which for now means only
files compiled with ICC or MSVC will show traces compiled.
But I have a future patch that may address this shortcoming.
Also since I don't know how to walk a pure haskell stack, I can for now
only show the last entry. I'm hoping to figure out how Apply.cmm works to
be able to walk the stalk and give more entries for pure haskell code.
In GHCi
```
$ echo main | inplace/bin/ghc-stage2.exe --interactive ./testsuite/tests/rts/derefnull.hs
GHCi, version 8.3.20170830: http://www.haskell.org/ghc/ :? for help
Ok, 1 module loaded.
Prelude Main>
Access violation in generated code when reading 0x0
Attempting to reconstruct a stack trace...
Frame Code address
* 0x77cde10 0xc370229 E:\..\base\dist-install\build\HSbase-4.10.0.0.o+0x190031
(base_ForeignziStorable_zdfStorableInt4_info+0x3f)
```
and compiled
```
Access violation in generated code when reading 0x0
Attempting to reconstruct a stack trace...
Frame Code address
* 0xf0dbd0 0x40bb01 E:\..\rts\derefnull.run\derefnull.exe+0xbb01
```
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3913
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As reported by Alex Lang, R_X86_64_NONE relocations
appear in per-package object files, not per-module object
files. This diff adds _NONE relocations for x86.
Reviewers: bgamari, geekosaur, austin, erikd, simonmar
Reviewed By: geekosaur
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4062
|
|
|
|
|
|
|
|
| |
Reviewers: angerman, austin, erikd, simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4034
|