| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
- Move the numaMap and nNumaNodes out of RtsFlags to Capability.c
- Add a test to tests/rts
|
|
|
|
|
|
|
|
| |
* Remove unused/old flags from the structs
* Update old comments
* Add missing flags to GHC.RTS
* Simplify GHC.RTS, remove C code and use hsc2hs instead
* Make ParFlags unconditional, and add support to GHC.RTS
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The aim here is to reduce the number of remote memory accesses on
systems with a NUMA memory architecture, typically multi-socket servers.
Linux provides a NUMA API for doing two things:
* Allocating memory local to a particular node
* Binding a thread to a particular node
When given the +RTS --numa flag, the runtime will
* Determine the number of NUMA nodes (N) by querying the OS
* Assign capabilities to nodes, so cap C is on node C%N
* Bind worker threads on a capability to the correct node
* Keep a separate free lists in the block layer for each node
* Allocate the nursery for a capability from node-local memory
* Allocate blocks in the GC from node-local memory
For example, using nofib/parallel/queens on a 24-core 2-socket machine:
```
$ ./Main 15 +RTS -N24 -s -A64m
Total time 173.960s ( 7.467s elapsed)
$ ./Main 15 +RTS -N24 -s -A64m --numa
Total time 150.836s ( 6.423s elapsed)
```
The biggest win here is expected to be allocating from node-local
memory, so that means programs using a large -A value (as here).
According to perf, on this program the number of remote memory accesses
were reduced by more than 50% by using `--numa`.
Test Plan:
* validate
* There's a new flag --debug-numa=<n> that pretends to do NUMA without
actually making the OS calls, which is useful for testing the code
on non-NUMA systems.
* TODO: I need to add some unit tests
Reviewers: erikd, austin, rwbarton, ezyang, bgamari, hvr, niteria
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2199
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: simonmar, duncan, erikd, austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2290
GHC Trac Issues: #12059
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use C compiler builtins for atomic SMP primitives. This saves a lot
of CPP ifdefs.
Add test for atomic xchg:
Test if __sync_lock_test_and_set() builtin stores the second argument.
The gcc manual says the actual value stored is implementation defined.
Test Plan: validate and eyeball generated assembler code
Reviewers: kgardas, simonmar, hvr, bgamari, austin, erikd
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2233
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a primitive operation to determine whether a particular
`MutableByteArray#` is backed by a pinned buffer.
Test Plan: Validate with included testcase
Reviewers: austin, simonmar
Reviewed By: austin, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2217
GHC Trac Issues: #12059
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes Cmm generation required to produce histograms when
compiling with -ticky flag, strips dead code from rts/Ticky.c and
reworks it to use a shared constant in both C and Haskell code.
Fixes #8308.
Test Plan: T8308
Reviewers: jstolarek, simonpj, austin
Reviewed By: simonpj
Subscribers: mpickering, simonpj, bgamari, mlen, thomie, jstolarek
Differential Revision: https://phabricator.haskell.org/D931
GHC Trac Issues: #8308
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to more const-correctness fixes this patch fixes an
infelicity of the previous const-correctness patch (995cf0f356) which
left `UNTAG_CLOSURE` taking a `const StgClosure` pointer parameter
but returning a non-const pointer. Here we restore the original type
signature of `UNTAG_CLOSURE` and add a new function
`UNTAG_CONST_CLOSURE` which takes and returns a const `StgClosure`
pointer and uses that wherever possible.
Test Plan: Validate on Linux, OS X and Windows
Reviewers: Phyx, hsyl20, bgamari, austin, simonmar, trofi
Reviewed By: simonmar, trofi
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SMP primitives were missing appropriate memory barriers
(sync, isync instructions) on all PowerPCs.
Use the built-ins _sync_* provided by gcc and clang. This
reduces code size significantly.
Remove broken mark for concprog001 on powerpc64. The referenced
ticket number (11259) was wrong.
Test Plan: validate on powerpc and ARM
Reviewers: erikd, austin, simonmar, bgamari, hvr
Reviewed By: bgamari, hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2225
GHC Trac Issues: #12070
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a function takes a pointer parameter and doesn't update what
the pointer points to, we can add `const` to the parameter
declaration to document that no updates occur.
Test Plan: Validate on Linux, OS X and Windows
Reviewers: austin, Phyx, bgamari, simonmar, hsyl20
Reviewed By: bgamari, simonmar, hsyl20
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Specifcally we want the MinGW compiler to use ISO print format
specfifiers.
Test Plan: Validate on Linux, OS X and Windows
Reviewers: Phyx, austin, bgamari, simonmar
Reviewed By: bgamari, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2192
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: hvr, austin, bgamari, simonmar
Reviewed By: bgamari, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2193
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can't define Stg{Int,Word} in terms of {,u}intptr_t because STG
depends on them being the exact same size as void*, and {,u}intptr_t
does not make that guarantee. Furthermore, we also need to define
StgHalf{Int,Word}, so the preprocessor if needs to stay. But we can at
least keep it in a single place instead of repeating it in various
files.
Also define STG_{INT,WORD}{8,16,32,64}_{MIN,MAX} and use it in HsFFI.h,
further reducing the need for CPP in other files.
Reviewers: austin, bgamari, simonmar, hvr, erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2182
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `nat` type was an alias for `unsigned int` with a comment saying
it was at least 32 bits. We keep the typedef in case client code is
using it but mark it as deprecated.
Test Plan: Validated on Linux, OS X and Windows
Reviewers: simonmar, austin, thomie, hvr, bgamari, hsyl20
Differential Revision: https://phabricator.haskell.org/D2166
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+RTS -AL<size> controls the total size of large objects that can be
allocated before a GC is triggered. Previously this was always just the
value of -A, and the limit mainly existed to prevent runaway allocation
in pathalogical programs that allocate a lot of large objects. However,
since the limit is shared between all cores, on a large multicore the
default becomes more restrictive, and can end up triggering GC well
before it would normally have been.
Arguably a better default would be A*N, but this is probably excessive.
Adding a flag lets you choose, and I've left the default as it was.
See docs for usage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the GC to use fewer threads than the number of capabilities.
At each GC, we choose some of the capabilities to be "idle", which means
that the thread running on that capability (if any) will sleep for the
duration of the GC, and the other threads will do its work. We choose
capabilities that are already idle (if any) to be the idle capabilities.
The idea is that this helps in the following situation:
* We want to use a large -N value so as to make use of hyperthreaded
cores
* We use a large heap size, so GC is infrequent
* But we don't want to use all -N threads in the GC, because that
thrashes the memory too much.
See docs for usage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The `lnat` type was deprecated in 2012 in commit 41737f12f9 with
a note to use `StgWord` instead.
Test Plan: Validate on Linux and OS X
Reviewers: simonmar, austin, Phyx, hvr, bgamari
Reviewed By: simonmar, Phyx, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2164
|
|
|
|
|
|
|
|
| |
Some old stuff related to the PAR way.
Reviewed by: austin, simonmar
Differential Revision: https://phabricator.haskell.org/D2137
|
|
|
|
|
|
|
|
| |
This allows an OS thread to specify which capability it should run on
when it makes a call into Haskell. It is intended for a fairly
specialised use case, when the client wants to have tighter control over
the mapping between OS threads and Capabilities - perhaps 1:1
correspondence, for example.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This macro is doubly redundant, first off all, ancient GCCs prior to
version 3.0 are not supported anymore, but more importantly, we require
a ISO C99 compliant compiler, so we can use the proper ISO C syntax
without worrying about compatibility.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: carter, thomie
Differential Revision: https://phabricator.haskell.org/D2121
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Saves us a CPP #if in MachDeps.h since we now can always rely on a
64-bit type being available.
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D2099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
scheme use the `CC=...` style scheme.
The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
stage{1,2,3}, while having a separate _STAGE0 set of env-vars
denote the bootstrap-toolchain flags/programs.
This should be simpler, less confusing, and somewhat more in line with
Autoconf's idioms (allowing us to reuse more of Autoconf rather than
(re)inventing our own confusing non-standard m4 macros to do stuff that
Autoconf could almost do already for us)
Morever, expose CC_STAGE0 as a so-called "precious" variable.
So now we can better control which bootstrapping gcc is used
(by default the one used by the stage0 ghc, unless CC_STAGE0 is
overriden)
```
Some influential environment variables:
CC_STAGE0 C compiler command (bootstrap)
CC C compiler command
CFLAGS C compiler flags
...
Use these variables to override the choices made by `configure' or to
help it to find libraries and programs with nonstandard names/locations.
```
Test Plan: I've tested that cross-compiling with
`--target=powerpc-linux-gnu` still works, and tried a few variants of
settting `CC=` and `CC_STAGE0=`; `./validate` passed as well
Reviewers: erikd, austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: Phyx, thomie
Differential Revision: https://phabricator.haskell.org/D2078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoids contention for the block allocator lock in the GC; this can be
seen in the gc_alloc_block_sync counter emitted by +RTS -s.
I experimented with this a while ago, and there was already
commented-out code for it in GCUtils.c, but I've now improved it so that
it doesn't result in significantly worse memory usage.
* The old method of putting spare blocks on ws->part_list was wasteful,
the spare blocks are now shared between all generations and retained
between GCs.
* repeated allocGroup() results in fragmentation, so I switched to using
allocLargeChunk() instead which is fragmentation-friendly; we already
use it for the same reason in nursery allocation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The last user of this file was the "-dynload wrapper"
which was removed in 169f5972d5398e75c4cf7f831b6ce703288ec73c
for addressing #4275
Reviewers: austin, erikd, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2098
GHC Trac Issues: #4275
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first phase of addressing #11757 which aims to make C99
support a base-line requirement for GHC and clean up the code-base to
use C99 facilities when sensible.
This patch exploits the logic/heuristic used by `AC_PROG_CC_C99` to
determine the flags needed in case the C compiler isn't able to compile
C99 code in its current mode. We can't use `AC_PROG_CC_C99` directly
though because GHC's build-system expects CC to contain a filename
without any flags, while `AC_PROG_CC_C99` would e.g. result in
`CC="gcc -std=gnu99"`. Morever, we support different `CC`s for
stage0/1/2, so we need a version of `AC_PROG_CC_C99` for which we can
specify the `CC`/`CFLAGS` variables to operate on. This is what
`FP_SET_CFLAGS_C99` does.
Note that Clang has been defaulting to C99+ for a long time, while GCC 5
defaults to C99+ as well. So this has mostly an affect on older GCCs
versions prior to 5.0 and possibly compilers other than GCC/Clang (which
are not officially supported for building GHC anyway).
Reviewers: kgardas, erikd, bgamari, austin
Reviewed By: erikd
Differential Revision: https://phabricator.haskell.org/D2045
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Long time ago, IRIX was way ahead of its time in the last century with
its SMP capabilities of scaling up to 1024 processors and other features
such as XFS or OpenGL that originated in IRIX and live on to this day in
other operating systems.
However, IRIX's last software update was in 2006 and support ended
around 2013 according to [1], so it's considered an extinct platform by
now. So this commit message is effectively an obituary for GHC's IRIX
support.
R.I.P. IRIX
[1]: https://en.wikipedia.org/wiki/IRIX
|
|
|
|
|
|
|
|
|
| |
At some point there may have been a reason for the
`INLINE_ME` macro, but not anymore...
Reviewed By: austin
Differential Revision: https://phabricator.haskell.org/D2041
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out the current macros for gnu90-style inline
semantics stopped working with GCC 5
(and possibly also with Apple's GCC) which switched on
`__GNUC_STDC_INLINE__` by default falling back to using the
suboptimal `static inline` mode.
However, C99 supports an equivalent (as far as our
use-case is concerned) `extern inline` mode.
See also
http://www.greenend.org.uk/rjk/tech/inline.html
for a write-up of gnu90 vs C99 semantics.
This patch also removes the MSVC case as VS2015 is supposed
to finally catch up to C99 (and C11), so we don't need any
special care for MSVC anymore.
Reviewed By: erikd, austin
Differential Revision: https://phabricator.haskell.org/D2039
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately (for inline `__asm__()` uses), IBM's `as` doesn't seem to support
local labels[1] like GNU `as` does so we need to workaround this when on AIX.
[1]: https://sourceware.org/binutils/docs/as/Symbol-Names.html#Symbol-Names
Turns out this also addresses the long-standing bug #485
Reviewed By: bgamari, trommler
Differential Revision: https://phabricator.haskell.org/D2029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the patch both Cmm and C symbols were declared
with 'EF_' macro:
#define EF_(f) extern StgFunPtr f()
but for Cmm symbols we know exact prototypes.
The patch splits there prototypes in to:
#define EFF_(f) void f() /* See Note [External function prototypes] */
#define EF_(f) StgFunPtr f(void)
Cmm functions are 'EF_' (External Functions),
C functions are 'EFF_' (External Foreign Functions).
While at it changed external C function prototype
to return 'void' to workaround ghc bug on m68k.
Described in detail in Trac #11395.
This makes simple tests work on m68k-linux target!
Thanks to Michael Karcher for awesome analysis
happening in Trac #11395.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
Test Plan: ran "hello world" on m68k successfully
Reviewers: simonmar, austin, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1975
GHC Trac Issues: #11395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 5d52d9b64c21dcf77849866584744722f8121389 removed
global 'blackhole_queue' in favour of new mechanism:
when TSO hits blackhole TSO blocks waiting for
'MessgaeBlackhole' delivery.
Patch removed unused global and updates stale comments.
Noticed by Yuras Shumovich.
Signed-off-by: Sergei Trofimovich <siarheit@google.com>
Test Plan: build test
Reviewers: simonmar, austin, Yuras, bgamari
Reviewed By: Yuras, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1953
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Linux assign F5 and F6 and D3 through D6 to caller-saved registers.
Fixes #11273
Test Plan: validate on powerpc (I validated on powerpc64)
Reviewers: bgamari, erikd, austin
Reviewed By: erikd, austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1914
GHC Trac Issues: #11273
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We are unable to produce load/store barriers for pre-ARMv7 targets.
Phab:D894 added dummy cases to SMP.h for these barriers to prevent the
build from failing under the assumption that there are no SMP-capable
devices of this vintage. However, #10433 points out that it is more
correct to simply set NOSMP for such targets.
Tested By: rwbarton
Test Plan: Validate
Reviewers: erikd, rwbarton, austin
Reviewed By: rwbarton
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1704
GHC Trac Issues: #10433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These are the names used by arm-linux-androideabi-objdump, so
it's helpful to have them here next to the Stg register mapping.
Reviewers: austin, erikd, bgamari
Reviewed By: erikd, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1840
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it seems that this closure type has not been in use since 5d52d9, so all
this is dead and untested code. This removes it. Some of the code might
be useful for a counting indirection as described in #10613, so when
implementing that, have a look at what this commit removes.
Test Plan: validate on harbormaster
Reviewers: austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1821
|
|
|
|
|
|
|
| |
In 3549c952b535803270872adaf87262f2df0295a4 a `include/ghcversions.h` include
file was introduced which defines `__GLASGOW_HASKELL__` as well.
So there's no need to define it twice.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Breakpoints become SCCs, so we have detailed call-stack info for
interpreted code. Currently this only works when GHC is compiled with
-prof, but D1562 (Remote GHCi) removes this constraint so that in the
future call stacks will be available without building your own GHCi.
How can you get a stack trace?
* programmatically: GHC.Stack.currentCallStack
* I've added an experimental :where command that shows the stack when
stopped at a breakpoint
* `error` attaches a call stack automatically, although since calls to
`error` are often lifted out to the top level, this is less useful
than it might be (ImplicitParams still works though).
* Later we might attach call stacks to all exceptions
Other related changes in this diff:
* I reduced the number of places that get ticks attached for
breakpoints. In particular there was a breakpoint around the whole
declaration, which was often redundant because it bound no variables.
This reduces clutter in the stack traces and speeds up compilation.
* I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few
other small cleanups
Test Plan: validate
Reviewers: ezyang, bgamari, austin, hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1595
GHC Trac Issues: #11047
|
|
|
|
| |
[skip ci]
|
|
|
|
|
| |
As otherwise <math.h> includes <stdlib.h> which breaks compilation
of .hc files
|
|
|
|
| |
Differential Revision: https://phabricator.haskell.org/D1198#40948
|
|
|
|
| |
Differential Revision: https://phabricator.haskell.org/D1198#40948
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin
Reviewed By: austin
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`derivedConstants` currently uses `System.Info.os` for decisions (which
doesn't necessarily reflect the build-target), as well as hardcoding
"/usr/bin/objdump" for openbsd.
This patch auto-detects `objdump` similiar to how `nm` is detected via
Autoconf as well as passing the target-os into `derivedConstants` via
commandline.
Reviewers: austin, kgardas, erikd, bgamari
Reviewed By: kgardas, erikd, bgamari
Subscribers: kgardas, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This hasn't been used for a very long time and will soon be superceded
by perf_events support.
Test Plan: validate
Reviewers: austin, simonmar
Reviewed By: austin, simonmar
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: validate
Reviewers: goldfire, erikd, rwbarton, simonpj, austin, simonmar, hvr
Reviewed By: simonpj
Subscribers: simonmar, thomie
Differential Revision: https://phabricator.haskell.org/D1103
GHC Trac Issues: #10678
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|