summaryrefslogtreecommitdiff
path: root/includes
Commit message (Collapse)AuthorAgeFilesLines
* Maintain cost-centre stacks in the interpreterSimon Marlow2015-12-212-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Random typo fixesHerbert Valerio Riedel2015-12-171-1/+1
| | | | [skip ci]
* On AIX we need -D_BSD defined in <Stg.h>Herbert Valerio Riedel2015-12-041-0/+5
| | | | | As otherwise <math.h> includes <stdlib.h> which breaks compilation of .hc files
* base: Add Haskell interface to ExecutionStackBen Gamari2015-11-231-0/+2
| | | | Differential Revision: https://phabricator.haskell.org/D1198#40948
* rts: Add LibdwPool, a pool for libdw sessionsBen Gamari2015-11-232-0/+23
| | | | Differential Revision: https://phabricator.haskell.org/D1198#40948
* rts: Expose more libdw symbolsBen Gamari2015-11-231-5/+9
|
* RtsFlags: Fix const warningBen Gamari2015-11-211-7/+7
| | | | | | | | | | Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1509
* Make `derivedConstants` more crosscompile-friendlyHerbert Valerio Riedel2015-11-191-0/+4
| | | | | | | | | | | | | | | | | | `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
* rts: Kill PAPI supportBen Gamari2015-11-181-26/+0
| | | | | | | | | | | | | | | 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
* Fix archive loading on Windows by the runtime loaderTamar Christina2015-11-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* New magic function for applying realWorld#Ben Gamari2015-11-121-0/+2
| | | | | | | | | | | | | | 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
* Allow the GHCi Linker to resolve related dependencies when loading DLLsTamar Christina2015-11-071-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make GHCi & TH work when the compiler is built with -profSimon Marlow2015-11-072-28/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Libdw: Fix symbol namingBen Gamari2015-11-011-2/+2
| | | | RTS convention is to use camel-case.
* cmm: Expose machine's stack and return address registerBen Gamari2015-11-012-0/+5
| | | | | | | | | | We will need to use these to setup proper unwinding information for the stg_stop_thread closure. This pokes a hole in the STG abstraction, exposing the machine's stack pointer register so that we can accomplish this. We also expose a dummy return address register, which corresponds to the register used to hold the DWARF return address. Differential Revision: https://phabricator.haskell.org/D1225
* Libdw: Add libdw-based stack unwindingBen Gamari2015-10-172-0/+91
| | | | | | | | | | | | | | | | | | | | | 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
* Fix signature of atomic builtinsAndreas Schwab2015-10-021-36/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is due to Andreas Schwab. This fixes #10926, which reports (on AArch64) errors of the form, ``` /tmp/ghc1492_0/ghc_1.hc:2844:25: warning: passing argument 1 of 'hs_atomic_xor64' makes pointer from integer without a cast [-Wint-conversion] _c1Ho = hs_atomic_xor64((*Sp) + (((Sp[1]) << 0x3UL) + 0x10UL), Sp[2]); ^ In file included from /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/Stg.h:273:0: 0, from /tmp/ghc1492_0/ghc_1.hc:3: /home/abuild/rpmbuild/BUILD/ghc-7.10.2/includes/stg/Prim.h:41:11: note: expected 'volatile StgWord64 * {aka volatile long unsigned int *}' but argument is of type 'long unsigned int' StgWord64 hs_atomic_xor64(volatile StgWord64 *x, StgWord64 val); ^ ``` Test Plan: Validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1300 GHC Trac Issues: #10926
* nativeGen PPC: fix > 16 bit offsets in stack handlingPeter Trommler2015-10-021-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement access to spill slots at offsets larger than 16 bits. Also allocation and deallocation of spill slots was restricted to 16 bit offsets. Now 32 bit offsets are supported on all PowerPC platforms. The implementation of 32 bit offsets requires more than one instruction but the native code generator wants one instruction. So we implement pseudo-instructions that are pretty printed into multiple assembly instructions. With pseudo-instructions for spill slot allocation and deallocation we can also implement handling of the back chain pointer according to the ELF ABIs. Test Plan: validate (especially on powerpc (32 bit)) Reviewers: bgamari, austin, erikd Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1296 GHC Trac Issues: #7830
* s/StgArrWords/StgArrBytes/Siddhanathan Shanmugam2015-09-113-18/+11
| | | | | | | | | | Rename StgArrWords to StgArrBytes (see Trac #8552) Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1233 GHC Trac Issues: #8552
* tracing: Kill EVENT_STARTUPBen Gamari2015-09-051-2/+2
| | | | | This has been unnecessary for quite some time due to the create/delete capability events.
* Build system: simplify install.mk.inThomas Miedema2015-08-211-4/+4
| | | | | | | | | | This will allow fixing #1851 more easily ("make install-strip" should work). This reverts 57e2a81c589103b50da80a9e378b1a11285bd521: "On Cygwin, use a Cygwin-style path for /bin/install's destination" Update submodule haddock and hsc2hs.
* Delete FastBoolThomas Miedema2015-08-211-94/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverses some of the work done in Trac #1405, and assumes GHC is smart enough to do its own unboxing of booleans now. I would like to do some more performance measurements, but the code changes can be reviewed already. Test Plan: With a perf build: ./inplace/bin/ghc-stage2 nofib/spectral/simple/Main.hs -fforce-recomp +RTS -t --machine-readable before: ``` [("bytes allocated", "1300744864") ,("num_GCs", "302") ,("average_bytes_used", "8811118") ,("max_bytes_used", "24477464") ,("num_byte_usage_samples", "9") ,("peak_megabytes_allocated", "64") ,("init_cpu_seconds", "0.001") ,("init_wall_seconds", "0.001") ,("mutator_cpu_seconds", "2.833") ,("mutator_wall_seconds", "4.283") ,("GC_cpu_seconds", "0.960") ,("GC_wall_seconds", "0.961") ] ``` after: ``` [("bytes allocated", "1301088064") ,("num_GCs", "310") ,("average_bytes_used", "8820253") ,("max_bytes_used", "24539904") ,("num_byte_usage_samples", "9") ,("peak_megabytes_allocated", "64") ,("init_cpu_seconds", "0.001") ,("init_wall_seconds", "0.001") ,("mutator_cpu_seconds", "2.876") ,("mutator_wall_seconds", "4.474") ,("GC_cpu_seconds", "0.965") ,("GC_wall_seconds", "0.979") ] ``` CPU time seems to be up a bit, but I'm not sure. Unfortunately CPU time measurements are rather noisy. Reviewers: austin, bgamari, rwbarton Subscribers: nomeata Differential Revision: https://phabricator.haskell.org/D1143 GHC Trac Issues: #1405
* Make headers C++ compatible (fixes #10700)Alexey Shmalko2015-07-302-12/+12
| | | | | | | | | | | | | | | | | Some headers used `new` as parameter name, which is reserved word in C++. This patch changes these names to `new_`. Test Plan: validate Reviewers: austin, ezyang, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1107 GHC Trac Issues: #10700
* Two step allocator for 64-bit systemsGiovanni Campagna2015-07-221-191/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: The current OS memory allocator conflates the concepts of allocating address space and allocating memory, which makes the HEAP_ALLOCED() implementation excessively complicated (as the only thing it cares about is address space layout) and slow. Instead, what we want is to allocate a single insanely large contiguous block of address space (to make HEAP_ALLOCED() checks fast), and then commit subportions of that in 1MB blocks as we did before. This is currently behind a flag, USE_LARGE_ADDRESS_SPACE, that is only enabled for certain OSes. Test Plan: validate Reviewers: simonmar, ezyang, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D524 GHC Trac Issues: #9706
* Implement PowerPC 64-bit native code backend for LinuxPeter Trommler2015-07-034-5/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the PowerPC 32-bit native code generator for "64-bit PowerPC ELF Application Binary Interface Supplement 1.9" by Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification -- OpenPOWER ABI for Linux Supplement" by IBM. The latter ABI is mainly used on POWER7/7+ and POWER8 Linux systems running in little-endian mode. The code generator supports both static and dynamic linking. PowerPC 64-bit code for ELF ABI 1.9 and 2 is mostly position independent anyway, and thus so is all the code emitted by the code generator. In other words, -fPIC does not make a difference. rts/stg/SMP.h support is implemented. Following the spirit of the introductory comment in PPC/CodeGen.hs, the rest of the code is a straightforward extension of the 32-bit implementation. Limitations: * Code is generated only in the medium code model, which is also gcc's default * Local symbols are not accessed directly, which seems to also be the case for 32-bit * LLVM does not work, but this does not work on 32-bit either * Must use the system runtime linker in GHCi, because the GHC linker for "static" object files (rts/Linker.c) for PPC 64-bit is not implemented. The system runtime (dynamic) linker works. * The handling of the system stack (register 1) is not ELF- compliant so stack traces break. Instead of allocating a new stack frame, spill code should use the "official" spill area in the current stack frame and deallocation code should restore the back chain * DWARF support is missing Fixes #9863 Test Plan: validate (on powerpc, too) Reviewers: simonmar, trofi, erikd, austin Reviewed By: trofi Subscribers: bgamari, arnons1, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D629 GHC Trac Issues: #9863
* Be aware of overlapping global STG registers in CmmSink (#10521)Reid Barton2015-06-251-0/+6
| | | | | | | | | | | | | | | | | | | Summary: On x86_64, commit e2f6bbd3a27685bc667655fdb093734cb565b4cf assigned the STG registers F1 and D1 the same hardware register (xmm1), and the same for the registers F2 and D2, etc. When mixing calls to functions involving Float#s and Double#s, this can cause wrong Cmm optimizations that assume the F1 and D1 registers are independent. Reviewers: simonpj, austin Reviewed By: austin Subscribers: simonpj, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D993 GHC Trac Issues: #10521
* Encode alignment in MO_Memcpy and friendsBen Gamari2015-06-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Alignment needs to be a compile-time constant. Previously the code generators had to jump through hoops to ensure this was the case as the alignment was passed as a CmmExpr in the arguments list. Now we take care of this up front. This fixes #8131. Authored-by: Reid Barton <rwbarton@gmail.com> Dusted-off-by: Ben Gamari <ben@smart-cactus.org> Tests for T8131 Test Plan: Validate Reviewers: rwbarton, austin Reviewed By: rwbarton, austin Subscribers: bgamari, carter, thomie Differential Revision: https://phabricator.haskell.org/D624 GHC Trac Issues: #8131
* Fix for CAF retention when dynamically loading & unloading codeSimon Marlow2015-06-082-2/+7
| | | | | | | | | | | | | In a situaion where we have some statically-linked code and we want to load and unload a series of objects, we need the CAFs in the statically-linked code to be retained indefinitely, while the CAFs in the dynamically-linked code should be GC'd as normal, so that we can detect when the code is unloadable. This was wrong before - we GC'd CAFs in the static code, leading to a crash in the rare case where we use a CAF, GC it, and then load a new object that uses it again. I also did some tidy up: RtsConfig now has a field keep_cafs to indicate whether we want CAFs to be retained in static code.
* rts: Fix aarch64 implementation of xchgErik de Castro Lopo2015-06-011-4/+2
| | | | | | | | | | | | | | | | In the previous implementation, the `stlxr` instruction clobbered the value that was supposed to be returned by the the `xchg` function. Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com> Test Plan: build on aarch64 Reviewers: austin, bgamari, rwbarton Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D932
* Add a TODO FIXME w.r.t. D894Austin Seipp2015-05-191-0/+5
| | | | | | | | | | | | As Reid mentioned in a comment on D894, the case fixed by this revision likely isn't really correct, because old ARM binaries could run on newer machines, meaning we need to detect at runtime whether we need a proper barrier. But in the mean time, this actually stops the build from failing - which is better off. So we'll just remember this when we fix it in the future. Signed-off-by: Austin Seipp <austin@well-typed.com>
* includes/stg/SMP.h: implement simple load_/store_load_barrier on armv6 and olderSergei Trofimovich2015-05-181-0/+4
| | | | | | | | | | | | | | | | | | | | Assuming there is no real SMP systems on these CPUs I've added only compiler barrier (otherwise write_barrier and friends need to be fixed as well). Patch also fixes build breakage reported in #10244. Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewers: rwbarton, nomeata, austin Reviewed By: nomeata, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D894 GHC Trac Issues: #10244
* rts: add "-no-rtsopts-suggestions" optionJavran Cheng2015-05-061-0/+3
| | | | | | | | | | | | | | | | | | Depends on D767 Setting this flag prevents RTS from giving RTS suggestions like "Use `+RTS -Ksize -RTS' to increase it." According to the comment @rwbarton made in #9579, sometimes "+RTS" suggestions don't make sense (e.g. when the program is precompiled and installed through package managers), we can encourage people to distribute binaries with either "-no-rtsopts-suggestions" or "-rtsopts". Reviewed By: erikd, austin Differential Revision: https://phabricator.haskell.org/D809 GHC Trac Issues: #9579
* Typos in error messages and in commentsGabor Greif2015-04-101-1/+1
|
* Replace hooks by callbacks in RtsConfig (#8785)Simon Marlow2015-04-073-27/+33
| | | | | | | | | | | | Summary: Hooks rely on static linking semantics, and are broken by -Bsymbolic which we need when using dynamic linking. Test Plan: Built it Reviewers: austin, hvr, tibbe Differential Revision: https://phabricator.haskell.org/D8
* fix bus errors on SPARC caused by unalignment access to alloc_limit (fixes ↵Karel Gardas2015-02-231-0/+3
| | | | | | | | | | #10043) Reviewers: austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D657
* Fix bad '... \\' escape in ghcversion.h generationHerbert Valerio Riedel2015-01-191-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | Today I learned about the peculiarities of escaping within single-quotes: Turns out, echo 'foo \\' emits foo \\ rather than escaping the '\'. Curiously, if you need to escape a ' within single-quotes, here's how to do it echo 'foo '\'' bar' which will emit foo ' bar This fixes #10002
* Trac #9878: Make the static form illegal in interpreted mode.Alexander Vershilov2015-01-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The entries of the static pointers table are expected to exist as object code. Thus we have ghci complain with an intelligible error message if the static form is used in interpreted mode. It also includes a fix to keysHashTable in Hash.c which could cause a crash. The iteration of the hashtable internals was incorrect. This patch has the function keysHashTable imitate the iteration in freeHashTable. Finally, we submit here some minor edits to comments and GHC.StaticPtr.StaticPtrInfo field names. Authored-by: Alexander Vershilov <alexander.vershilov@tweag. Authored-by: Facundo Domínguez <facundo.dominguez@tweag.io> Test Plan: ./validate Reviewers: simonpj, hvr, austin Reviewed By: austin Subscribers: carter, thomie, qnikst, mboes Differential Revision: https://phabricator.haskell.org/D586 GHC Trac Issues: #9878
* Trac #9878: Have StaticPointers support dynamic loading.Alexander Vershilov2015-01-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: A mutex is used to protect the SPT. unsafeLookupStaticPtr and staticPtrKeys in GHC.StaticPtr are made monadic. SPT entries are removed in a destructor function of modules. Authored-by: Facundo Domínguez <facundo.dominguez@tweag.io> Authored-by: Alexander Vershilov <alexander.vershilov@tweag.io> Test Plan: ./validate Reviewers: austin, simonpj, hvr Subscribers: carter, thomie, qnikst, mboes Differential Revision: https://phabricator.haskell.org/D587 GHC Trac Issues: #9878
* Groom comments related to StaticPointers.Facundo Domínguez2014-12-221-2/+1
| | | | | | Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D575
* Fix typo in GLASGOW_HASKELL_PATCHLEVEL2 macroHerbert Valerio Riedel2014-12-221-1/+1
| | | | This typo slipped in through 3549c952b535803270872adaf87262f2df0295a4
* commentsSimon Marlow2014-12-151-1/+11
|
* Fix comments (#8254)Simon Marlow2014-12-151-3/+1
|
* powerpc: fix and enable shared libraries by default on linuxSergei Trofimovich2014-12-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: And fix things all the way down to it. Namely: - remove 'r30' from free registers, it's an .LCTOC1 register for gcc. generated .plt stubs expect it to be initialised. - fix PicBase computation, which originally forgot to use 'tmp' reg in 'initializePicBase_ppc.fetchPC' - mark 'ForeighTarget's as implicitly using 'PicBase' register (see comment for details) - add 64-bit MO_Sub and test on alloclimit3/4 regtests - fix dynamic label offsets to match with .LCTOC1 offset Signed-off-by: Sergei Trofimovich <siarheit@google.com> Test Plan: validate passes equal amount of vanilla/dyn tests Reviewers: simonmar, erikd, austin Reviewed By: erikd, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D560 GHC Trac Issues: #8024, #9831
* Link pre-ARMv6 spinlocks into all RTS variantsJoachim Breitner2014-12-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For compatibility with ARM machines from pre v6, the RTS provides implementations of certain atomic operations. Previously, these were only included in the threaded RTS. But ghc (the library) contains the code in compiler/cbits/genSym.c, which uses these operations if there is more than one capability. But there is only one libHSghc, so the linker wants to resolve these symbols in every case. By providing these operations in all RTSs, the linker is happy. The only downside is a small amount of dead code in the non-threaded RTS on old ARM machines. Test Plan: It helped here. Reviewers: bgamari, austin Reviewed By: bgamari, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D564 GHC Trac Issues: #8951
* Implement -XStaticValuesFacundo Domínguez2014-12-093-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As proposed in [1], this extension introduces a new syntactic form `static e`, where `e :: a` can be any closed expression. The static form produces a value of type `StaticPtr a`, which works as a reference that programs can "dereference" to get the value of `e` back. References are like `Ptr`s, except that they are stable across invocations of a program. The relevant wiki pages are [2, 3], which describe the motivation/ideas and implementation plan respectively. [1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards Haskell in the cloud. SIGPLAN Not., 46(12):118–129, September 2011. ISSN 0362-1340. [2] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers [3] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/ImplementationPlan Authored-by: Facundo Domínguez <facundo.dominguez@tweag.io> Authored-by: Mathieu Boespflug <m@tweag.io> Authored-by: Alexander Vershilov <alexander.vershilov@tweag.io> Test Plan: `./validate` Reviewers: hvr, simonmar, simonpj, austin Reviewed By: simonpj, austin Subscribers: qnikst, bgamari, mboes, carter, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D550 GHC Trac Issues: #7015
* Revert "Revert "Add purgeObj() to remove the symbol table entries for an ↵Simon Marlow2014-12-051-0/+3
| | | | | | object"" This reverts commit 7932b2adaecac6c86038176d909c20ad1b1f9604.
* Revert "Add purgeObj() to remove the symbol table entries for an object"Simon Peyton Jones2014-12-021-3/+0
| | | | | | | | | | | | | | | | This reverts commit 9e6e4796437a7fc23e83605a45db9b2663570123. I reverted it because one of these two patches 9e6e4796437a7fc23e83605a45db9b2663570123 Add purgeObj() b5e8b3b162b3ff15ae6caf1afc659565365f54a8 Make the linker API thread-safe causes a seg-fault on Windows. The seg-fault happens immediately the linker is invoked, in ghci or in Template Haskell. I believe that it is the "linker API thread-safe" commit that causes the seg-fault; it happens even if the "purgeObj" commit alone is reverted. But since the two patches mess with the same code, to revert the "linker API" patch I had revert both.
* Add purgeObj() to remove the symbol table entries for an objectSimon Marlow2014-11-281-0/+3
| | | | | | | | This allows us to replace an object without actually unloading the old object, which is necessary when we know we have references to the old object so it can't be completely unloaded. Using unloadObj() would cause the GC (CheckUnload) to repeatedly and fruitlessly try to unload the old object.
* Add +RTS -n<size>: divide the nursery into chunksSimon Marlow2014-11-251-0/+1
| | | | See the documentation for details.
* Make clearNursery freeSimon Marlow2014-11-251-0/+21
| | | | | | | | | | | | | | | | | | | | | Summary: clearNursery resets all the bd->free pointers of nursery blocks to make the blocks empty. In profiles we've seen clearNursery taking significant amounts of time particularly with large -N and -A values. This patch moves the work of clearNursery to the point at which we actually need the new block, thereby introducing an invariant that blocks to the right of the CurrentNursery pointer still need their bd->free pointer reset. This should make things faster overall, because we don't need to clear blocks that we don't use. Test Plan: validate Reviewers: AndreasVoellmy, ezyang, austin Subscribers: thomie, carter, ezyang, simonmar Differential Revision: https://phabricator.haskell.org/D318
View Lorry Controller Status