summaryrefslogtreecommitdiff
path: root/rts
Commit message (Collapse)AuthorAgeFilesLines
* fix EBADF unqueueing in select backend (Trac #10590)Sergei Trofimovich2015-07-073-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Alexander found a interesting case: 1. We have a queue of two waiters in a blocked_queue 2. first file descriptor changes state to RUNNABLE, second changes to INVALID 3. awaitEvent function dequeued RUNNABLE thread to a run queue and attempted to dequeue INVALID descriptor to a run queue. Unqueueing INVALID fails thusly: #3 0x000000000045cf1c in barf (s=0x4c1cb0 "removeThreadFromDeQueue: not found") at rts/RtsMessages.c:42 #4 0x000000000046848b in removeThreadFromDeQueue (...) at rts/Threads.c:249 #5 0x000000000049a120 in removeFromQueues (...) at rts/RaiseAsync.c:719 #6 0x0000000000499502 in throwToSingleThreaded__ (...) at rts/RaiseAsync.c:67 #7 0x0000000000499555 in throwToSingleThreaded (..) at rts/RaiseAsync.c:75 #8 0x000000000047c27d in awaitEvent (wait=rtsFalse) at rts/posix/Select.c:415 The problem here is a throwToSingleThreaded function that tries to unqueue a TSO from blocked_queue, but awaitEvent function leaves blocked_queue in a inconsistent state while traverses over blocked_queue: case RTS_FD_IS_READY: IF_DEBUG(scheduler, debugBelch("Waking up blocked thread %lu\n", (unsigned long)tso->id)); tso->why_blocked = NotBlocked; tso->_link = END_TSO_QUEUE; // Here we break the queue head pushOnRunQueue(&MainCapability,tso); break; Signed-off-by: Sergei Trofimovich <siarheit@google.com> Test Plan: tested on a sample from T10590 Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: qnikst, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1024 GHC Trac Issues: #10590, #4934
* Update comments around blackholesSimon Marlow2015-07-073-11/+14
| | | | | | | | | | Test Plan: validate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1047
* Fix offset calculation in __stg_gc_funSimon Marlow2015-07-061-2/+3
| | | | | | | | | | | | | | Summary: We were not treating the offset as a signed field in this rare case, so it would blow up if the offset was negative. Test Plan: Looked at the assembly Reviewers: austin, bgamari, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1042
* rts: fix incorrect checking start for -x arguments (#9839)Nikita Kartashov2015-07-061-2/+16
| | | | | | | | | After previous fix, flag combinations such as -xt and -xc resulted in an error due to the fact that the checking started from index 2, which was always 'x' in that case. Now they are correctly processed. Differential Revision: https://phabricator.haskell.org/D1039
* Implement PowerPC 64-bit native code backend for LinuxPeter Trommler2015-07-033-1/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* disable check for .init_array section on OpenBSDKarel Gardas2015-07-011-2/+2
| | | | | | | | | | | | Summary: The patch disables check for .init_array section on OpenBSD. It is provided in OpenBSD ports tree and was done by Matthias Kilian. Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1023
* Fix deadlock (#10545)Simon Marlow2015-06-265-130/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | yieldCapability() was not prepared to be called by a Task that is not either a worker or a bound Task. This could happen if we ended up in yieldCapability via this call stack: performGC() scheduleDoGC() requestSync() yieldCapability() and there were a few other ways this could happen via requestSync. The fix is to handle this case in yieldCapability(): when the Task is not a worker or a bound Task, we put it on the returning_workers queue, where it will be woken up again. Summary of changes: * `yieldCapability`: factored out subroutine waitForWorkerCapability` * `waitForReturnCapability` renamed to `waitForCapability`, and factored out subroutine `waitForReturnCapability` * `releaseCapabilityAndQueue` worker renamed to `enqueueWorker`, does not take a lock and no longer tests if `!isBoundTask()` * `yieldCapability` adjusted for refactorings, only change in behavior is when it is not a worker or bound task. Test Plan: * new test concurrent/should_run/performGC * validate Reviewers: niteria, austin, ezyang, bgamari Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D997 GHC Trac Issues: #10545
* Fix for crash in setnumcapabilities001Simon Marlow2015-06-261-6/+12
| | | | | | | getNewNursery() was unconditionally incrementing next_nursery, which is normally fine but it broke an assumption in storageAddCapabilities(). This manifested as an occasional crash in the setnumcapabilities001 test.
* powerpc: add basic support for PLT relocations (#10402)Sergei Trofimovich2015-06-231-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a93ab43ab5f40cadbedea2f6342b93c245e91434 enabled support for proper PIC relocations from assembler. Commit adds support for relocations of type: R_PPC_REL16_HI R_PPC_REL16_HA R_PPC_REL16_LO R_PPC_PLTREL24 They are used only when GHC is built in DYNAMIC_GHC_PROGRAMS = NO mode. Verified by running the following test: // cat a.c #include <stdio.h> void ffi_a_hello (int i) { fprintf (stderr, "WEEEEEEEE: i=%d\n", i); } -- cat A.hs {-# LANGUAGE ForeignFunctionInterface #-} module A where import Foreign.C foreign import ccall "ffi_a_hello" a :: CInt -> IO () # ghc -fPIC -c a.c -fforce-recomp # ghc -fPIC -c A.hs -fforce-recomp # ghc --interactive ./a.o A ... *A> a 42 WEEEEEEEE: i=42 See gory details in Trac #10402. Signed-off-by: Colin Watson <cjwatson@debian.org> Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewed By: bgamari, austin Differential Revision: https://phabricator.haskell.org/D996 GHC Trac Issues: #10402
* Rename $1_$2_$3_LIB_NAME to LIB_FILE.Edward Z. Yang2015-06-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we introduced user-friendly library names (e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to be written out by ghc-cabal, $1_$2_LIB_NAME. What I didn't realize at the time was that this conflicts with an existing variable in the build system, $1_$2_$3_LIB_NAME, which (confusingly) refers to something like 'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'. This is pretty confusing (despite never conflicting), so I renamed this variable to LIB_FILE for enhanced greppability. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1002
* Encode alignment in MO_Memcpy and friendsBen Gamari2015-06-161-4/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * Encode alignment in MO_Memcpy and friendsBen Gamari2015-06-161-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Do not copy stack after stack overflow, refix #8435Flaviu Andrei Csernik (archblob)2015-06-121-0/+1
|/ | | | | | | | | | | | | | | | | | Summary: This was reverted in d70b19bfb5ed79b22c2ac31e22f46782fc47a117 and is a part of the reason for #10445. Test Plan: validate Reviewers: ezyang, simonmar, austin Reviewed By: simonmar, austin Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D938 GHC Trac Issues: #8435
* Squash typos in commentsGabor Greif2015-06-122-2/+2
|
* Fix for CAF retention when dynamically loading & unloading codeSimon Marlow2015-06-084-11/+43
| | | | | | | | | | | | | 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.
* Don't call DEAD_WEAK finalizer again on shutdown (#7170)Simon Marlow2015-06-013-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There's a race condition like this: # A foreign pointer gets promoted to the last generation # It has its finalizer called manually # We start shutting down the runtime in `hs_exit_` from the main thread # A minor GC starts running (`scheduleDoGC`) on one of the threads # The minor GC notices that we're in `SCHED_INTERRUPTING` state and advances to `SCHED_SHUTTING_DOWN` # The main thread tries to do major GC (with `scheduleDoGC`), but it exits early because we're in `SCHED_SHUTTING_DOWN` state # We end up with a `DEAD_WEAK` left on the list of weak pointers of the last generation, because it relied on major GC removing it from that list This change: * Ignores DEAD_WEAK finalizers when shutting down * Makes the major GC on shutdown more likely * Fixes a bogus assert Test Plan: before this diff https://ghc.haskell.org/trac/ghc/ticket/7170#comment:5 reproduced and after it doesn't Reviewers: ezyang, austin, simonmar Reviewed By: simonmar Subscribers: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D921 GHC Trac Issues: #7170
* Newline after type of allocate().Edward Z. Yang2015-06-011-1/+2
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* rts: Fix typo in commentErik de Castro Lopo2015-05-241-2/+2
|
* rts: add "-no-rtsopts-suggestions" optionJavran Cheng2015-05-064-27/+40
| | | | | | | | | | | | | | | | | | 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
* Better hints when RTS options not available (Trac #9579)Javran Cheng2015-04-173-7/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides user with a better hint when most RTS options are not available (not compiled with `-rtsopts`). A new field "rtsOptsEnabled" is added into RtsFlags.MiscFlags to tell the availablity of RTS options. Some concerns: * Unlike other flag fields in "libraries/base/GHC/RTS/Flags.hsc", "RtsOptsEnabled" is defined in "includes/RtsAPI.h" and lacks constant macros. Therefore In "GHC.RTS", "RtsOptsEnabled" simply derives Enum instance and reads as of type "CInt". * There are other ways to change RTS options (e.g. `-with-rtsopts`), but it might be too verbose to mention. Test Plan: validate Reviewers: austin, hvr, thomie, simonmar Reviewed By: thomie Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D767 GHC Trac Issues: #9579
* Typos in error messages and in commentsGabor Greif2015-04-102-2/+2
|
* rts/Linker.c: distinct between DATA and CODE labels when importingSergei Trofimovich2015-04-071-18/+42
| | | | | | | | | | | | | | | | | | | | The patch is a last major piece to make unregisterised GHC build under GCC's link-time optimizer. Before the patch we imported everything external as functions. Now we distinct between global variables and functions. The difference is crucial on ia64 and a complement to fixes: > d82f592522eb8e063276a8a8c87ab93e18353c6b > CMM: add a mechanism to import C .data labels > e18525fae273f4c1ad8d6cbe1dea4fc074cac721 > pprC: declare extern cmm primitives as functions, not data Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D797
* Add -n to the RTS help outputSimon Marlow2015-04-071-0/+1
|
* Add +RTS -O<size> to control the minimum old gen sizeSimon Marlow2015-04-071-0/+9
|
* Replace hooks by callbacks in RtsConfig (#8785)Simon Marlow2015-04-0715-87/+177
| | | | | | | | | | | | 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
* Stop profiling output from running together (#8811)Dave Laing2015-04-061-20/+54
| | | | | | Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D779
* rts/linker: make an error msg a debug msgAustin Seipp2015-04-031-2/+3
| | | | | | This fixes more testsuite failures on Windows. Signed-off-by: Austin Seipp <austin@well-typed.com>
* rts: check arguments to flags that don't have anyCarlos Tomé2015-03-231-7/+28
| | | | | | | | | | | | | | | | There were some flags of the RTS that when given an argument (which they don't have) were not firing an error. e.g -Targument when the flag -T has no argument. Now this is an error and affects the following flags: -B -w -T -Z -P -Pa -c -t Signed-off-by: Carlos Tomé <carlostome1990@gmail.com> Reviewed By: austin, thomie, hvr Differential Revision: https://phabricator.haskell.org/D748 GHC Trac Issues: #9839
* fix bus error (misaligned data access) on SPARC in __decodeDouble_Int64Karel Gardas2015-03-221-3/+3
| | | | | | | | Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D749
* Clarify meaning of the RTS `taskCount` variableThomas Miedema2015-03-221-1/+1
| | | | | | | | | | | | | | | | | | | In #9261, there was some confusion about the meaning of the taskCount stats variable in the rts. It turns out that taskCount is not decremented when a worker task is stopped (i.e. from workerTaskStop), but only when freeMyTask is called, which frees the task bound to the current thread. So taskCount is the current number of bound tasks + the total number of worker tasks. This makes the calculation of the current number of bound tasks in rts/Stats.c correct _as is_. [skip ci] Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D746
* Remove comments and flag for GranSimThomas Miedema2015-03-194-7/+1
| | | | | | | | | The GranSim code was removed in dd56e9ab and 297b05a9 in 2009, and perhaps other commits I couldn't find. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D737
* RTS/IOManager: fix trac issue #9722.Andreas Voellmy2015-03-091-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Whenever the RTS has been inactive for idleGCDelayTime, the idle timer fires and calls wakeUpRts(), which in turn calls ioManagerWakeup(), which in turn writes a byte (or a few) to a file descriptor (stored in the io_manager_wakeup_fd variable) registered by the TimerManager and on which the TimerManager will wait. (Note that the write will only occur if the file descriptor is non-negative.) When the RTS shuts down, it shuts down the TimerManager, and in this process the file descriptor stored in io_manager_wakeup_fd is closed. In the error case, the idle timer fires after the close of the file occurs, and then the write() call in ioManagerWakeup() fails and the aforementioned error message gets printed. This patch solves the problem by (1) having the TimerManager (via Control) write -1 to io_manager_wakeup_fd just before closing the file descriptor written in io_manager_wakeup_fd, and (2) having ioManagerWakeup() ignore an error returned by write() in the case that the write returned -1 and the io_manager_wakeup_fd is -1. Reviewers: austin, simonmar, hvr, thomie Reviewed By: thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D722 GHC Trac Issues: #9722
* Fix -Werror build failure in RtsMainTamar Christina2015-03-031-1/+1
| | | | | | | | | | | | | | | | | | | Summary: Something in Excn.h's include chain is loading _mingw.h which is defining a macro that PosixSource.h is going to define. _mingw.h's version properly checks if it has already been defined and skips it, so fixing the warning can be done by just including Excn.h later (moved it to before last include). Test Plan: ./validate Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D698
* Replaced SEH handles with VEH handlers which should work uniformly across ↵Tamar Christina2015-03-0310-221/+263
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | x86 and x64 Summary: On Windows, the default action for things like division by zero and segfaults is to pop up a Dr. Watson error reporting dialog if the exception is unhandled by the user code. This is a pain when we are SSHed into a Windows machine, or when we want to debug a problem with gdb (gdb will get a first and second chance to handle the exception, but if it doesn't the pop-up will show). veh_excn provides two macros, `BEGIN_CATCH` and `END_CATCH`, which will catch such exceptions in the entire process and die by printing a message and calling `stg_exit(1)`. Previously this code was handled using SEH (Structured Exception Handlers) however each compiler and platform have different ways of dealing with SEH. `MSVC` compilers have the keywords `__try`, `__catch` and `__except` to have the compiler generate the appropriate SEH handler code for you. `MinGW` compilers have no such keywords and require you to manually set the SEH Handlers, however because SEH is implemented differently in x86 and x64 the methods to use them in GCC differs. `x86`: SEH is based on the stack, the SEH handlers are available at `FS[0]`. On startup one would only need to add a new handler there. This has a number of issues such as hard to share handlers and it can be exploited. `x64`: In order to fix the issues with the way SEH worked in x86, on x64 SEH handlers are statically compiled and added to the .pdata section by the compiler. Instead of being thread global they can now be Image global since you have to specify the `RVA` of the region of code that the handlers govern. You can on x64 Dynamically allocate SEH handlers, but it seems that (based on experimentation and it's very under-documented) that the dynamic calls cannot override static SEH handlers in the .pdata section. Because of this and because GHC no longer needs to support < windows XP, the better alternative for handling errors would be using the in XP introduced VEH. The bonus is because VEH (Vectored Exception Handler) are a runtime construct the API is the same for both x86 and x64 (note that the Context object does contain CPU specific structures) and the calls are the same cross compilers. Which means this file can be simplified quite a bit. Using VEH also means we don't have to worry about the dynamic code generated by GHCi. Test Plan: Prior to this diff the tests for `derefnull` and `divbyzero` seem to have been disabled for windows. To reproduce the issue on x64: 1) open ghci 2) import GHC.Base 3) run: 1 `divInt` 0 which should lead to ghci crashing an a watson error box displaying. After applying the patch, run: make TEST="derefnull divbyzero" on both x64 and x86 builds of ghc to verify fix. Reviewers: simonmar, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D691 GHC Trac Issues: #6079
* Give full-precision time for BEGIN_SAMPLE/END_SAMPLE.Edward Z. Yang2015-03-021-4/+2
| | | | | | | | | | | | Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D679
* rts/linker: ignore unknown PE sectionsTamar Christina2015-02-231-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed. Test Plan: See the file `ghcilinkerbug.zip` in #9907. 1) unzip file content. 2) open examplecpp.cabal and change base <4.8 to <4.9. 3) execute cabal file with cabal repl. Applying the patch makes `cabal repl` in step 3) work. Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D671 GHC Trac Issues: #9907, #7103, #10051, #7056, #8546
* fix bus errors on SPARC caused by unalignment access to alloc_limit (fixes ↵Karel Gardas2015-02-233-8/+14
| | | | | | | | | | #10043) Reviewers: austin, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D657
* Don't truncate traceEvents to 512 bytes (#8309)Thomas Miedema2015-02-173-33/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Don't call postLogMsg to post a user msg, because it truncates messages to 512 bytes. Rename traceCap_stderr and trace_stderr to vtraceCap_stderr and trace_stderr, to signal that they take a va_list (similar to vdebugBelch vs debugBelch). See #3874 for the original reason behind traceFormatUserMsg. See the commit msg in #9395 (d360d440) for a discussion about using null-terminated strings vs strings with an explicit length. Test Plan: Run `cabal install ghc-events` and inspect the result of `ghc-events show` on an eventlog file created with `ghc -eventlog Test.hs` and `./Test +RTS -l`, where Test.hs contains: ``` import Debug.Trace main = traceEvent (replicate 510 'a' ++ "bcd") $ return () ``` Depends on D655. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D656 GHC Trac Issues: #8309
* Add missing va_end to va_startThomas Miedema2015-02-171-0/+2
| | | | | | | | | | | | Summary: See also ab9711d8. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D655
* Fix #10017Andreas Voellmy2015-02-021-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In the threaded RTS, a signal is delivered from the RTS to Haskell user code by writing to file that one of the IO managers watches (via an instance of GHC.Event.Control.Control). When the IO manager receives the signal, it calls GHC.Conc.Signal.runHandlers to invoke Haskell signal handler. In the move from a single IO manager to one IO manager per capability, the behavior was (wrongly) extended so that a signal is delivered to every event manager (see #9423), each of which invoke Haskell signal handlers, leading to multiple invocations of Haskell signal handlers for a single signal. This change fixes this problem by having the RTS (in generic_handler()) notify only the Control instance used by the TimerManager, rather than all the per-capability IO managers. Reviewers: austin, hvr, simonmar, Mikolaj Reviewed By: simonmar, Mikolaj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D641
* RTS : Fix StgRun for aarch64-linux (#9935).Erik de Castro Lopo2015-01-271-8/+10
| | | | | | | | | | | | | | | | | | | | Summary: The GCC assembler doesn't seem to recognise the 'fp' and 'lr' register names which are aliases for 'x29' and 'x30' respectively. Depends on D598. Test Plan: validate Reviewers: lukexi, bgamari, austin Reviewed By: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D599 GHC Trac Issues: #9935
* comments onlySimon Marlow2015-01-201-0/+2
|
* CMM: add a mechanism to import C .data labelsSergei Trofimovich2015-01-192-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This introduces new .cmm syntax for import: 'import' 'CLOSURE' <identifier>; Currently cmm syntax allows importing only function labels: import pthread_mutex_lock; but sometimes ghc needs to import global gariables or haskell closures: import ghczmprim_GHCziTypes_True_closure; import base_ControlziExceptionziBase_nestedAtomically_closure; import ghczmprim_GHCziTypes_False_closure; import sm_mutex; It breaks on ia64 where there is a difference in pointers to data and pointer to functions. Patch fixes threaded runtime on ia64 where dereference of 'sm_mutex' from CMM led to incurrect location. Exact breakage machanics are the same as in e18525fae273f4c1ad8d6cbe1dea4fc074cac721 Merge into the 7.10 branch Signed-off-by: Sergei Trofimovich <siarheit@google.com> Test Plan: passes ./validate, makes ghci work on ghc-7.8.4 Reviewers: simonmar, simonpj, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D622
* Trac #9384: fix increasing capabilites number for eventlog.Alexander Vershilov2015-01-181-0/+9
| | | | | | | | | | | | | | | | | | Event log had inconcistent support for increacing capabilies number, as header were not inserted in capability buffer. It resulted in a ghc-events crash (see #9384). This commit fixes this issue by inserting required header when number of capabilies grows. Reviewers: simonmar, Mikolaj, trofi, austin Reviewed By: Mikolaj, trofi, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D592 GHC Trac Issues: #9384
* Trac #9878: Make the static form illegal in interpreted mode.Alexander Vershilov2015-01-161-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Optimise scavenge_large_srt_bitmapSimon Marlow2015-01-131-12/+22
| | | | | | | | | | | Very large modules can sometimes contain very large SRT bitmaps (this is a separate problem that I need to look into). The large bitmaps often contain a lot of zeros, so this patch skips over empty words in the bitmap. It makes a dramatic difference in the particular example that I saw, where an old gen GC was taking 0.5s before this change and 0.07s after it.
* Allow the linker to run concurrently with the GCSimon Marlow2015-01-133-2/+16
|
* Trac #9878: Have StaticPointers support dynamic loading.Alexander Vershilov2015-01-132-7/+55
| | | | | | | | | | | | | | | | | | | | | | | 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-222-2/+2
| | | | | | Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D575
* Add unwind information to CmmPeter Wortmann2014-12-162-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Unwind information allows the debugger to discover more information about a program state, by allowing it to "reconstruct" other states of the program. In practice, this means that we explain to the debugger how to unravel stack frames, which comes down mostly to explaining how to find their Sp and Ip register values. * We declare yet another new constructor for CmmNode - and this time there's actually little choice, as unwind information can and will change mid-block. We don't actually make use of these capabilities, and back-end support would be tricky (generate new labels?), but it feels like the right way to do it. * Even though we only use it for Sp so far, we allow CmmUnwind to specify unwind information for any register. This is pretty cheap and could come in useful in future. * We allow full CmmExpr expressions for specifying unwind values. The advantage here is that we don't have to make up new syntax, and can e.g. use the WDS macro directly. On the other hand, the back-end will now have to simplify the expression until it can sensibly be converted into DWARF byte code - a process which might fail, yielding NCG panics. On the other hand, when you're writing Cmm by hand you really ought to know what you're doing. (From Phabricator D169)
View Lorry Controller Status