| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous strategy caused problems on Windows, as pointed out
at [1]
[1]: https://phabricator.haskell.org/rGHC900c47f88784#133905
Reviewers: Phyx, bgamari, erikd, simonmar
Reviewed By: Phyx
Subscribers: rwbarton, carter
GHC Trac Issues: #15671
Differential Revision: https://phabricator.haskell.org/D5356
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was previously only defined (and therefore shipped) when DEBUG is
defined. This patch defines it regardless of DEBUG. This will help fix
hadrian on OS X [1].
[1]: https://github.com/snowleopard/hadrian/issues/614
Test Plan: The error from hadrian#614 is gone
Reviewers: bgamari, erikd, simonmar
Reviewed By: simonmar
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: A better alternative to D4657.
Test Plan:
```
cd testsuite/tests/codeGen/should_run
../../../../inplace/bin/ghc-stage2 -debug cgrun001
nm cgrun001 | grep findPtr
```
Reviewers: bgamari, Phyx, erikd
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4683
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit b2ff5dde399cd012218578945ada1d9ff68daa35 "Fix #15038"
added new stable closure 'absentSumFieldError_closure' to
base package. This closure is used in rts package.
Unfortunately the symbol was not explicitly exported and build
failed on windows as:
```
"inplace/bin/ghc-stage1" -o ...hsc2hs.exe ...
rts/dist/build/libHSrts.a(RtsStartup.o): In function `hs_init_ghc':
rts/RtsStartup.c:272:0: error:
undefined reference to `base_ControlziExceptionziBase_absentSumFieldError_closure'
|
272 | getStablePtr((StgPtr)absentSumFieldError_closure);
| ^
```
This change adds 'absentSumFieldError_closure' to explicit export
into libHSbase.def.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
| |
This was an oversight from 2671cccde749ed64129097358f81bff43480cdb9
as it wasn't obvious to assume one would go the trouble to manually
construct the pkg-db entries... :-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's often hard to debug things like segfaults on Windows,
mostly because gdb isn't always of use and users don't know
how to effectively use it.
This patch provides a way to create a crash drump by passing
`+RTS --generate-crash-dumps` as an option. If any unhandled
exception is triggered a dump is made that contains enough
information to be able to diagnose things successfully.
Currently the created dumps are a bit big because I include
all registers, code and threads information.
This looks like
```
$ testsuite/tests/rts/derefnull.run/derefnull.exe +RTS
--generate-crash-dumps
Access violation in generated code when reading 0000000000000000
Crash dump created. Dump written to:
E:\msys64\tmp\ghc-20170901-220250-11216-16628.dmp
```
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari, simonmar
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3912
|
|
|
|
| |
Our new CPP linter enforces this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The endevor to drop the `-Wl,-u,<sym>` requirement for linking the rts,
base, ,... turned out to be less fruitful than I had hoped. However it
did turn up a few dead symbols, that are referenced but for which the
definition seems to have diminished.
Reviewers: austin, rwbarton, geekosaur, erikd, simonmar, bgamari
Reviewed By: geekosaur, simonmar
Subscribers: thomie, snowleopard
Differential Revision: https://phabricator.haskell.org/D3350
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some platforms have pthreads support available without linking against
libpthread (and indeed don't even offer a libpthread to link against).
One example of this is Android's bionic library. Teach the RTS about
this case.
Test Plan: Validate while cross-compiling targetting Android on aarch64
Reviewers: simonmar, austin, hvr, erikd, rwbarton
Subscribers: danharaj, thomie, erikd, snowleopard
Differential Revision: https://phabricator.haskell.org/D3149
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit makes various improvements and addresses some issues with
Compact Regions (aka Compact Normal Forms).
This was the most important thing I wanted to fix. Compaction
previously prevented GC from running until it was complete, which
would be a problem in a multicore setting. Now, we compact using a
hand-written Cmm routine that can be interrupted at any point. When a
GC is triggered during a sharing-enabled compaction, the GC has to
traverse and update the hash table, so this hash table is now stored
in the StgCompactNFData object.
Previously, compaction consisted of a deepseq using the NFData class,
followed by a traversal in C code to copy the data. This is now done
in a single pass with hand-written Cmm (see rts/Compact.cmm). We no
longer use the NFData instances, instead the Cmm routine evaluates
components directly as it compacts.
The new compaction is about 50% faster than the old one with no
sharing, and a little faster on average with sharing (the cost of the
hash table dominates when we're doing sharing).
Static objects that don't (transitively) refer to any CAFs don't need
to be copied into the compact region. In particular this means we
often avoid copying Char values and small Int values, because these
are static closures in the runtime.
Each Compact# object can support a single compactAdd# operation at any
given time, so the Data.Compact library now enforces mutual exclusion
using an MVar stored in the Compact object.
We now get exceptions rather than killing everything with a barf()
when we encounter an object that cannot be compacted (a function, or a
mutable object). We now also detect pinned objects, which can't be
compacted either.
The Data.Compact API has been refactored and cleaned up. A new
compactSize operation returns the size (in bytes) of the compact
object.
Most of the documentation is in the Haddock docs for the compact
library, which I've expanded and improved here.
Various comments in the code have been improved, especially the main
Note [Compact Normal Forms] in rts/sm/CNF.c.
I've added a few tests, and expanded a few of the tests that were
there. We now also run the tests with GHCi, and in a new test way
that enables sanity checking (+RTS -DS).
There's a benchmark in libraries/compact/tests/compact_bench.hs for
measuring compaction speed and comparing sharing vs. no sharing.
The field totalDataW in StgCompactNFData was unnecessary.
Test Plan:
* new unit tests
* validate
* tested manually that we can compact Data.Aeson data
Reviewers: gcampax, bgamari, ezyang, austin, niteria, hvr, erikd
Subscribers: thomie, simonpj
Differential Revision: https://phabricator.haskell.org/D2751
GHC Trac Issues: #12455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When rts is forked it doesn't update toplevel handler, so UserInterrupt
exception is sent to Thread1 that doesn't exist in forked process.
We install toplevel handler when fork so signal will be delivered to the
new main thread.
Fixes #12903
Reviewers: simonmar, austin, erikd, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2770
GHC Trac Issues: #12903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It looks like I broke the OS X build with 55d535da10dd, hopefully this
should fix it.
Test Plan: Harbourmaster
Reviewers: austin, bgamari, erikd
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2705
GHC Trac Issues: #12455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported in #12812, the runtime system fails to build when linked
with gold due to a missing dependency on libpthread.
Additionally, rts/package.conf.in uses the WORD_SIZE_IN_BITS macro
defined by MachDeps.h, which it does not #include. Fix this.
Test Plan: Validate with gold linker
Reviewers: hsyl20, austin, erikd, simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2695
GHC Trac Issues: #12816
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The configure script sets `HAVE_LIBNUMA` to either `0` or `1` but this
file had `#ifdef HAVE_LIBNUMA`. This surfaced as a side-effect of
1050e46b5b. CPP is really hard to get right.
Test Plan: Validate on harbourmaster
Reviewers: simonmar, bgamari, austin, mpickering
Reviewed By: mpickering
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2631
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a fast, non-blocking, asynchronous, interface to tryPutMVar that
can be called from C/C++.
It's useful for callback-based C/C++ APIs: the idea is that the callback
invokes hs_try_putmvar(), and the Haskell code waits for the callback to
run by blocking in takeMVar.
The callback doesn't block - this is often a requirement of
callback-based APIs. The callback wakes up the Haskell thread with
minimal overhead and no unnecessary context-switches.
There are a couple of benchmarks in
testsuite/tests/concurrent/should_run. Some example results comparing
hs_try_putmvar() with using a standard foreign export:
./hs_try_putmvar003 1 64 16 100 +RTS -s -N4 0.49s
./hs_try_putmvar003 2 64 16 100 +RTS -s -N4 2.30s
hs_try_putmvar() is 4x faster for this workload (see the source for
hs_try_putmvar003.hs for details of the workload).
An alternative solution is to use the IO Manager for this. We've tried
it, but there are problems with that approach:
* Need to create a new file descriptor for each callback
* The IO Manger thread(s) become a bottleneck
* More potential for things to go wrong, e.g. throwing an exception in
an IO Manager callback kills the IO Manager thread.
Test Plan: validate; new unit tests
Reviewers: niteria, erikd, ezyang, bgamari, austin, hvr
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2501
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch resulted from the discussion in D2431 and should be merged
first.
@erikd and @trommler reported errors like
```
/home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts_thr.a(PrimOps.thr_o
): In function `c14_info':
(.text+0x2b8): undefined reference to `hs_cmpxchg32'
/home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts_thr.a(PrimOps.thr_o
): In function `c5e_info':
(.text+0xac4): undefined reference to `hs_cmpxchg32'
/home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts_thr.a(PrimOps.thr_o
): In function `c8b_info':
(.text+0x1198): undefined reference to `hs_cmpxchg32'
/home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts_thr.a(PrimOps.thr_o
): In function `c8b_info':
(.text+0x122c): undefined reference to `hs_cmpxchg32'
/home/erikd/Git/ghc-upstream/rts/dist/build/libHSrts_thr.a(PrimOps.thr_o
): In function `c8b_info':
(.text+0x12ec): undefined reference to `hs_cmpxchg32'
```
on PowerPC. @simonmar suggests to add the specific exports to
`rts/package.conf.in`. This patch does exactly that, including all
other atomic ops as they probably (maybe someone can verify?) suffer
from the same problem on PPC.
Test Plan: Please make sure to build on PPC.
Reviewers: erikd, austin, bgamari, simonmar, trommler
Reviewed By: erikd, trommler
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2435
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Configure/build with and without --enable-libdw
Reviewers: trofi, hvr, austin, simonmar, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2276
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enforces linkage with pthread library on OpenBSD. This is
done in order to avoid linker errors when linking with libffi which
requires POSIX threading but itself is not linked with libpthread
directly. So client binaries (of libffi) needs to link against
libpthread explicitly
Reviewers: austin, bgamari
Reviewed By: bgamari
Subscribers: thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds basic support to the RTS for DWARF-assisted unwinding of the
Haskell and C stack via libdw. This only adds the infrastructure;
consumers of this functionality will be introduced in future diffs.
Currently we are carrying the initial register collection code in
Libdw.c but this will eventually make its way upstream to libdw.
Test Plan: See future patches
Reviewers: Tarrasch, scpmw, austin, simonmar
Reviewed By: austin, simonmar
Subscribers: simonmar, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D1196
GHC Trac Issues: #10656
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit contains a Cabal submodule update which unifies installed
package IDs and package keys under a single notion, a Component ID.
We update GHC to keep follow this unification. However, this commit
does NOT rename installed package ID to component ID and package key to
unit ID; the plan is to do that in a companion commit.
- Compiler info now has "Requires unified installed package IDs"
- 'exposed' is now expected to contain unit keys, not IPIDs.
- Shadowing is no more. We now just have a very simple strategy
to deal with duplicate unit keys in combined package databases:
if their ABIs are the same, use the latest one; otherwise error.
Package databases maintain the invariant that there can only
be one entry of a unit ID.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, austin, bgamari, hvr, goldfire
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1184
GHC Trac Issues: #10714
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When we call runHandlers, we must pass it a ForeignPtr. To ensure that
this happens, we introduce a wrapper that receives a plain Ptr and
converts it into a ForeignPtr. Then we adjust startSignalHandlers in
rts/posix/Signals.c to call the wrapper instead of calling runHandlers
directly.
Reviewers: hvr, austin, rwbarton, simonmar
Reviewed By: austin, simonmar
Subscribers: simonmar, thomie, carter
Differential Revision: https://phabricator.haskell.org/D515
GHC Trac Issues: #9817
|
|
|
|
|
|
|
|
| |
This reverts commit f0fcc41d755876a1b02d1c7c79f57515059f6417.
New changes: now works on 32-bit platforms too. I added some basic
support for 64-bit subtraction and comparison operations to the x86
NCG.
|
|
|
|
|
|
|
| |
This reverts commit 35672072b4091d6f0031417bc160c568f22d0469.
Conflicts:
compiler/main/DriverPipeline.hs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In preparation for indirecting all references to closures,
we rename _closure to _static_closure to ensure any old code
will get an undefined symbol error. In order to reference
a closure foobar_closure (which is now undefined), you should instead
use STATIC_CLOSURE(foobar). For convenience, a number of these
old identifiers are macro'd.
Across C-- and C (Windows and otherwise), there were differing
conventions on whether or not foobar_closure or &foobar_closure
was the address of the closure. Now, all foobar_closure references
are addresses, and no & is necessary.
CHARLIKE/INTLIKE were not changed, simply alpha-renamed.
Part of remove HEAP_ALLOCED patch set (#8199)
Depends on D265
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Test Plan: validate
Reviewers: simonmar, austin
Subscribers: simonmar, ezyang, carter, thomie
Differential Revision: https://phabricator.haskell.org/D267
GHC Trac Issues: #8199
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch set makes us no longer assume that a package key is a human
readable string, leaving Cabal free to "do whatever it wants" to allocate
keys; we'll look up the PackageId in the database to display to the user.
This also means we have a new level of qualifier decisions to make at the
package level, and rewriting some Safe Haskell error reporting code to DTRT.
Additionally, we adjust the build system to use a new ghc-cabal output
Make variable PACKAGE_KEY to determine library names and other things,
rather than concatenating PACKAGE/VERSION as before.
Adds a new `-this-package-key` flag to subsume the old, erroneously named
`-package-name` flag, and `-package-key` to select packages by package key.
RFC: The md5 hashes are pretty tough on the eye, as far as the file
system is concerned :(
ToDo: safePkg01 test had its output updated, but the fix is not really right:
the rest of the dependencies are truncated due to the fact the we're only
grepping a single line, but ghc-pkg is wrapping its output.
ToDo: In a later commit, update all submodules to stop using -package-name
and use -this-package-key. For now, we don't do it to avoid submodule
explosion.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
Test Plan: validate
Reviewers: simonpj, simonmar, hvr, austin
Subscribers: simonmar, relrod, carter
Differential Revision: https://phabricator.haskell.org/D80
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before the patch any call to 'select()' with 'bad_fd' led to:
- unblocking of all threads
- hiding exception for 'threadWaitRead bad_fd'
The patch fixes both cases in this way:
after 'select()' failure we iterate over each blocked descriptor
and poll individually to see it's actual status, which is:
- READY (move to run queue)
- BLOCKED (leave in blocked queue)
- INVALID (send an IOErrror exception)
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
| |
Problems were found on 32-bit platforms, I'll commit again when I have a fix.
This reverts the following commits:
54b31f744848da872c7c6366dea840748e01b5cf
b0534f78a73f972e279eed4447a5687bd6a8308e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit b0534f78a73f972e279eed4447a5687bd6a8308e added new exported rts symbols,
but slightly misspelled them.
Observer on first compiled program:
> Linking dist/build/haskell-updater/haskell-updater ...
> /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(Schedule.o): In function `scheduleWaitThread':
> (.text+0xc4c): undefined reference to `base_GHCziIOziException_allocationLimitExceeded_closure'
> /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(RtsStartup.o): In function `hs_init_ghc':
> (.text+0x2fa): undefined reference to `base_GHCziIOziException_allocationLimitExceeded_closure'
> collect2: error: ld returned 1 exit status
CC: Simon Marlow <marlowsd@gmail.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This tracks the amount of memory allocation by each thread in a
counter stored in the TSO. Optionally, when the counter drops below
zero (it counts down), the thread can be sent an asynchronous
exception: AllocationLimitExceeded. When this happens, given a small
additional limit so that it can handle the exception. See
documentation in GHC.Conc for more details.
Allocation limits are similar to timeouts, but
- timeouts use real time, not CPU time. Allocation limits do not
count anything while the thread is blocked or in foreign code.
- timeouts don't re-trigger if the thread catches the exception,
allocation limits do.
- timeouts can catch non-allocating loops, if you use
-fno-omit-yields. This doesn't work for allocation limits.
I couldn't measure any impact on benchmarks with these changes, even
for nofib/smp.
|
|
|
|
|
|
|
|
|
| |
passed explicitely
Issue #8748
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
| |
Now with less Mac-breakage.
With this change, I can get a working stage1/stage2 compiler using
Clang 3.4svn, which can be used to link working executables!
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
|
|
| |
This reverts commit 991f285e681e8541632502d05d8a46de2d44b7bd.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
|
|
| |
This reverts commit ebf97ad146173afd9e094f4975aa33717ed3a11e.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
|
|
| |
This reverts commit 5dc74f385f1bbc9248ed950af255b946677c2ff9.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
|
|
|
|
| |
Technically, '-u' is an ld option, not a compiler option,
and clang considers this argument unused. Hence, we must
explicitly forward this to the linker.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
| |
Patch from Peter Trommler
|
|
|
|
| |
explicitly link against any dependent library
|
|
|
|
|
|
|
|
|
|
|
| |
I think overall the new approach is simpler. Rather than unpacking
the libffi.a and putting the .o files into our libHSrts.a, we just
use the libffi.a.
This change also means that when compiling programs for the dyn
way, they get explicitly linked against libffi.so (rather than
relying on librts.so being linked against it). This might
fix a problem on FreeBSD, where programs cannot find libffi.so.
|
| |
|
|
|
|
|
|
| |
returning.
This enables the IO manager to change the number of IO loops it uses (usually one per capability).
|
|
|
|
|
|
|
|
|
|
| |
Based on patch from Peter Trommler:
From 293495d40f62e691520331a41c6d85d82e120169 Mon Sep 17 00:00:00 2001
From: Peter Trommler <ptrommler@acm.org>
Date: Sun, 21 Oct 2012 18:47:01 +0200
Subject: [PATCH] Add configure option to use system provided libffi This
fixes track # 5743 and #4496.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This required various build system changes to get the build to go
through.
In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
to find their libraries. In the future, we might change the inplace tree
to be the same shape as an installed tree instead. However, this would
mean changing the way we do installation, as currently we use cabal's
installation methods to install the libraries, but that only works if
the libraries are under libraries/foo/dist-install/build/..., rather
than in inplace/lib/...
|
|
|
|
|
| |
This means we only need to build one copy of the program, which
will make life simpler as I plan to add more variants.
|