| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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:
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Long ago, the stable name table and stable pointer tables were one.
Now, they are separate, and have significantly different
implementations. I believe the time has come to finish the split
that began in #7674.
* Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`.
* Give each table its own mutex.
* Add FFI functions `hs_lock_stable_ptr_table` and
`hs_unlock_stable_ptr_table` and document them.
These are intended to replace the previously undocumented
`hs_lock_stable_tables` and `hs_lock_stable_tables`,
which are now documented as deprecated synonyms.
* Make `eqStableName#` use pointer equality instead of unnecessarily
comparing stable name table indices.
Reviewers: simonmar, bgamari, erikd
Reviewed By: bgamari
Subscribers: rwbarton, carter
GHC Trac Issues: #15555
Differential Revision: https://phabricator.haskell.org/D5084
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a function to the RTS linker API which lets the
user check the status of dynamically linked objects.
It was initially proposed by @afarmer in D2068.
It's useful for testing the linker and also for detecting retention
problems in production.
It takes a path, because it's easier to use path as key instead of producing
some stable handle.
It returns an enum instead of bool, because I see no reason for destroying
information. All the complexity is already out in the open, so there's
nothing to save the users from.
Test Plan: ./validate
Reviewers: simonmar, Phyx, bgamari, austin, erikd
Reviewed By: Phyx, bgamari
Subscribers: rwbarton, afarmer, thomie
Differential Revision: https://phabricator.haskell.org/D3963
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: `GHCi.loadDll "/usr/lib/libc++.so` now works on FreeBSD.
Reviewers: austin, bgamari, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3841
|
|
|
|
| |
[skip ci]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The import library support added for 7.10.3 was only a partial one.
This support was predicated on using file extensions to determine
whether or not a library was an import library. It also couldn't handle
libraries with multiple dll pointers.
This is a rewrite of that patch and fully integrating it into the normal
archive parsing and loading routines. This solves a host of issues,
among others allowing us to finally use `-lgcc_s`.
This also fixes a problem with our previous implementation, where we
just loaded the DLL and moved on. Doing this had the potential of using
the wrong symbol at resolve time. Say a DLL already loaded (A.dll) has
symbol a exported (dependency of another dll perhaps).
We find an import library `B.lib` explicitly defining an export of `a`.
we load `B.dll` but this gets put after `A.dll`, at resolve time we
would use the value from `A` instead of `B` which is what we wanted.
Test Plan: ./valide and make test TEST=13606
Reviewers: austin, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force
GHC Trac Issues: #13606, #12499, #12498
Differential Revision: https://phabricator.haskell.org/D3513
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a follow-up to @angerman 's refactoring for ELF
that happened with e5e8646d3c6af82549b55fbee6764b087144a7ec
My previous commit a6675a93efe7cae2f206508047a39e73ce4e92a5
corrected a typedef redefinition issue with GCC v4.4
(which is pervasive with RHEL 6). Now the problem has resurfaced.
Instead of dancing after the different compiler's pipe, I decided
to eliminate the typedefs altogether and refer to the struct
namespace explicitly.
Added a note to describe why typedefs are not
applied on customisable structs.
Reviewers: austin, bgamari, erikd, simonmar
Subscribers: rwbarton, thomie, angerman
Differential Revision: https://phabricator.haskell.org/D3527
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fills out the extended `info` structs, and will be subsequently
used in the arm and arm64 linker for elf.
Depends on: D3446, D3459
Reviewers: bgamari, austin, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3447
|
|
|
|
| |
Our new CPP linter enforces this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do check for symCmd, to set the info->nlist value, but forgot to do
the same check for info->names. Thus when trying to extract stroff from
symCmd, we hit a segfault.
Test Plan: The validation failure on windows is rather suspicious...
let's try this one
Reviewers: bgamari, adinapoli, austin, erikd, simonmar
Reviewed By: adinapoli
Subscribers: thomie, rwbarton
Differential Revision: https://phabricator.haskell.org/D3468
|
|
|
|
|
|
| |
This causes validation failures on Windows.
This reverts commit 6c05b27e5bafe9f232e7014f4760335f5e3ba591.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do check for symCmd, to set the info->nlist value, but
forgot to do the same check for info->names. Thus when trying to
extract stroff from symCmd, we hit a segfault.
Reviewers: bgamari, adinapoli, austin, erikd, simonmar
Reviewed By: bgamari, adinapoli
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3459
|
|
|
|
| |
These were missed in D3278.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds ocInit_MachO function, used to populate the extended
ObjectCode structure, and the corresponding stgFree.
It also adds defines for iOS, such that MachO.o is also compiled for iOS
targets.
Depends on D3239
---
This is just one of the pieces for the rts linker
support for ios (aarch64-macho)
---
The following diagram and legend tries to explain the dependencies a
bit:
```
.- D3240
v
D3255 <- D3252 <- This <- D3239
^
'- D3238
```
- In D3238 we started allowing preloading object code with mmap
in iOS, where we can't have r+w+x.
- In D3239 we introduced a richer extension of the object code
data type to make working with mach-o files easier.
- In D3240 we set the stage to allow loading archives (.a) on iOS
- In D3251 we added init and deinit functions to populate and
depopulate the enriched object code data structure for mach-o
files.
- In D3252 we refactored most of the MachO.c file to use the
new types and data structure.
- in D3255 we finally introduce the aarch64-mach-o linker.
Reviewers: rwbarton, bgamari, austin, erikd, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3251
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This diff introduces MachOTypes, to reduce the need to typing `struct`
all the time. It also coaleces the 64 and non 64 structs. It also adds
additional fiedls to the object code structure for macho, which makes
working with macho object code much simpler and requires less passing
around of variabls or address recomputation for the header, symbol
table, etc...
Furthermore this diff introduces a type for a linked list of stubs.
I had to move the #ifdef from the bottom of the file up, to be able to
extend the object code structure conditional on the use of the macho file format.
This is just one of the pieces for the rts linker
support for ios (aarch64-macho)
---
The following diagram and legend tries to explain the dependencies a
bit:
```
.- D3240
v
D3255 <- D3252 <- D3251 <- This
^
'- D3238
```
- In D3238 we started allowing preloading object code with mmap
in iOS, where we can't have r+w+x.
- In D3239 we introduced a richer extension of the object code
data type to make working with mach-o files easier.
- In D3240 we set the stage to allow loading archives (.a) on iOS
- In D3251 we added init and deinit functions to populate and
depopulate the enriched object code data structure for mach-o
files.
- In D3252 we refactored most of the MachO.c file to use the
new types and data structure.
- in D3255 we finally introduce the aarch64-mach-o linker.
Reviewers: austin, erikd, simonmar, rwbarton, bgamari
Subscribers: rwbarton, thomie, ryantrinkle
Differential Revision: https://phabricator.haskell.org/D3239
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While we do not yet enable mmap for ios builds. If we later do, we must
not try to mmap r+w+x, on iOS as that clearly fails.
This diff also adds a check for the successful mmaping.
I don't think we can blanket change this to r+w for every case, unless
we are absolutely sure that we are going to remap this and set +x where
needed.
This is just one of the pieces for the rts linker support for ios
(aarch64-macho)
---
The following diagram and legend tries to explain the dependencies a
bit:
```
.- D3240
v
D3255 <- D3252 <- D3251 <- D3239
^
'- This
```
- In D3238 we started allowing preloading object code with mmap
in iOS, where we can't have r+w+x.
- In D3239 we introduced a richer extension of the object code
data type to make working with mach-o files easier.
- In D3240 we set the stage to allow loading archives (.a) on iOS
- In D3251 we added init and deinit functions to populate and
depopulate the enriched object code data structure for mach-o
files.
- In D3252 we refactored most of the MachO.c file to use the
new types and data structure.
- in D3255 we finally introduce the aarch64-mach-o linker.
Reviewers: ezyang, austin, erikd, simonmar, bgamari, rwbarton
Reviewed By: bgamari
Subscribers: rwbarton, ryantrinkle, thomie
Differential Revision: https://phabricator.haskell.org/D3238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a unfortunate workaround in place for the fact that most
packages out there use POSIX names for symbols even on Windows. This
means that we have to recognize e.g. both `_ungetch` and `ungetch`.
The former is the actual symbol name on windows and the latter is the
POSIX variant. The problem is that on normal windows programs `ungetch`
should not be in the global namespace.
To work around this, we now mark the deprecated symbols as weak symbols
in the global namespace. This provides the flexibility we need:
* If you use the symbol without defining it, we assume you meant to use
the POSIX variant.
* If you actually define the symbol, we'll hence forth use that
definition and assume you didn't mean to use POSIX code. This is how
MingW64's wrapper also works.
This requires D3028.
Fixes #13210.
Test Plan: ./validate
Reviewers: austin, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D3154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The symbol not found error that is triggered
during lazy-loading was a bit chaotic before.
This reformats it a bit to:
```
ghc-stage2.exe: | E:\...\libLLVMSupport.a: unknown symbol `_ZN4llvm5APIntC1Ejyb'
ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm5APInt14AssignSlowCaseERKS0_'
ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm13ConstantRangeC1ENS_5APIntES1_'
ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm14FoldingSetImplC2Ej'
ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm15LLVMContextImplD1Ev'
ghc-stage2.exe: | E:\...\libLLVMLTO.a: unknown symbol `_ZN4llvm11LLVMContextD1Ev'
ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZNK4llvm5Value10getContextEv'
ghc-stage2.exe: ^^ Could not load 'LLVMIsMultithreaded', dependency unresolved.
See top entry above.
```
I have also thought about also showing the demangled names, as it may
be useful for the end user.
`libgcc` seems to provide a method for this so we wouldn't need any
extra dependency.
Any thoughts on this or would it not be useful?
Reviewers: austin, erikd, simonmar, bgamari
Reviewed By: bgamari
Subscribers: RyanGlScott, thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D3027
GHC Trac Issues: #13093, #13113
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Power ISA says the result of a division by zero is undefined. So
ignore stdout on PowerPC 64-bit systems.
Disable ext-interp tests on 64-bit PowerPC. We don't have support for
PowerPC 64-bit ELF in the RTS linker, which is needed for the external
interpreter.
Test Plan: ./validate
Reviewers: austin, simonmar, hvr, erikd, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2782
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate on lots of platforms
Reviewers: erikd, simonmar, austin
Reviewed By: erikd, simonmar
Subscribers: michalt, thomie
Differential Revision: https://phabricator.haskell.org/D2699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: DemiMarie, austin, simonmar, erikd
Reviewed By: DemiMarie
Subscribers: Phyx, thomie, hvr
Differential Revision: https://phabricator.haskell.org/D2642
GHC Trac Issues: #12388
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2650
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2649
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2648
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: These will be needed across source files shortly.
Test Plan: Validate
Reviewers: erikd, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2647
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2646
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2644
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, austin, simonmar
Reviewed By: erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2643
|
|
|
|
| |
This reverts commit 488a9ed3440fe882ae043ba7f44fed4e84e679ce.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: erikd, simonmar, austin, DemiMarie
Reviewed By: erikd, simonmar, DemiMarie
Subscribers: hvr, thomie
Differential Revision: https://phabricator.haskell.org/D2615
GHC Trac Issues: #12388
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: simonmar, austin, erikd
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2614
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When trying to profile a plugin, ghc mysteriously segfaulted. Upon
closer examination the segfault happend due to a `->prevStack` lookup
on a NULL pointer.
A new CostCentre: Unknown is introduced that is set, if ccsapp and
ccsfn are of equal depth (e.g. 0), and do not have a common CostCentre
in their stacks.
Reviewers: bgamari, simonmar, austin, erikd
Reviewed By: simonmar
Subscribers: Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D2551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With the introduction of 8.0.1 We've stopped supporting in GHCi
the use of POSIX functions under their deprecated names on Windows.
This to be compatible with object and libraries from the most
popular compilers on the platform (Microsoft and Intel compilers).
However this brings a confusing disparity between the compiled and
interpreted behavior since MingW-W64 does support the deprecated names.
Also It seems clear that package writers won't update their packages to
properly support Windows. As such I have added redirects in the RTS
for the deprecated functions as listed on
https://msdn.microsoft.com/en-us/library/ms235384.aspx.
This won't export the functions (as in, they won't be in the symbol table
of compiled code for the RTS.) but we inject them into the symbol table
of the dynamic linker at startup.
Test Plan:
./validate
and
make test TEST="ffi017 ffi021"
Reviewers: thomie, simonmar, RyanGlScott, bgamari, austin, hvr, erikd
Reviewed By: simonmar, bgamari
Subscribers: RyanGlScott, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2500
GHC Trac Issues: #12209, #12497, #12496
|
|
|
|
| |
This reverts commit 6377757918c1e7f63638d6f258cad8d5f02bb6a7.
|
|
|
|
| |
This reverts commit 01f449f4ffd2c4f23bfe5698b9f1b98a86276900.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This field is never set, but it was being tested and used to decide
whether to resolve an object or not. This caused non-deterministic
crashes when using the RTS linker (see #12230).
I suspect this is not the correct fix, but putting it up so that Phyx
can tell us what the right fix should be.
Test Plan: validate
Reviewers: austin, Phyx, bgamari, erikd
Subscribers: erikd, thomie, ezyang
Differential Revision: https://phabricator.haskell.org/D2371
GHC Trac Issues: #12230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Rename it to `USED_IF_x86_64_HOST_ARCH` to make it more like the existing
`USED_IF` macros as suggested by Simon Marlow.
Test Plan: Build on x86_64 windows
Reviewers: Phyx, bgamari, simonmar, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2365
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Build on x86_64/linux, x86_64/darwin and powerpc/linux
Reviewers: Phyx, bgamari, simonmar, austin
Reviewed By: Phyx
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Code already existed in the RTS to add thin library support for non-Windows
operating systems. This adds it to Windows as well.
ar thin libraries have the exact same format as normal archives except they
have a different magic string and they don't copy the object files into the
archive.
Instead each header entry points to the location of the object file on disk.
This is useful when a library is only created to satisfy a compile time dependency
instead of to be distributed. This saves the time required for copying.
Test Plan: ./validate and new test T11788
Reviewers: austin, bgamari, simonmar, erikd
Reviewed By: bgamari, simonmar
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2323
GHC Trac Issues: #11788
|