summaryrefslogtreecommitdiff
path: root/rts
Commit message (Collapse)AuthorAgeFilesLines
* rts/Linker.c: mark ia64 as 64-bit ELF, drop unused branchesSergei Trofimovich2015-12-301-4/+6
| | | | Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* rts/PrimOps.cmm: fix UNREG profiled buildSergei Trofimovich2015-12-301-0/+3
| | | | | | | | | | | | | | | Brought 'CCS_MAIN' into scope, otherwise UNREG prof build is unhappy: rts_dist_HC rts/dist/build/PrimOps.p_o /tmp/ghc25593_0/ghc_3.hc: In function 'clB_entry': /tmp/ghc25593_0/ghc_3.hc:2983:24: error: error: 'CCS_MAIN' undeclared (first use in this function) *((P_)(_cly+8)) = (W_)&CCS_MAIN; ^ Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* rts/Linker(ARM): Ensure all code sections are flushed from cacheBen Gamari2015-12-281-1/+9
| | | | | | | | | | | | Test Plan: Validate with T12299 Reviewers: hsyl20, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1708 GHC Trac Issues: #11299
* RTS: Detect powerpc64le as ELF 64-bit systemPeter Trommler2015-12-271-1/+1
| | | | | | | | | | | | | | Test Plan: validate Reviewers: simonmar, erikd, austin, bgamari Reviewed By: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1672 GHC Trac Issues: #11269
* Linker(ELF): Fix addProddableBlocks usageBen Gamari2015-12-271-1/+1
| | | | | | | | | | | | | | | The range marked as proddable didn't actually match the range that we mapped. This fixed `ghc-api/T8628` et al on ARM. Test Plan: Validate Reviewers: austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1700 GHC Trac Issues: #11289
* Linker: Reenable Thumb supportBen Gamari2015-12-271-4/+24
| | | | | I believe this ought to be okay now since we only produce ARM-encoded objects. Added a Note describing the state of things.
* Linker: Fix cut-and-paste error in debug outputBen Gamari2015-12-271-1/+1
|
* - fix gc_thread related compilation failure on Solaris/i386 platformKarel Gardas2015-12-231-1/+2
| | | | | | | | | | | | | Summary: This patch fixes gc_thread related compilation failure on Solaris/i386 platform. It uses Linux way of __thread declared gc_thread variable for register starving i386 from now. Reviewers: bgamari, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1688
* Modify Nmax to maxN Trac #10728MarcelineVQ2015-12-231-14/+40
| | | | | | | | | | | | | | | | | Added test and changed -Nmax to -maxN, -n was taken Noticed strange -m behavoir and fixed -m from quietly ignoring being passed invalid opts, e.g. "-msasd" Reviewers: simonmar, hvr, austin, thomie, bgamari Reviewed By: hvr, thomie, bgamari Subscribers: bgamari, hvr, thomie, simonmar Differential Revision: https://phabricator.haskell.org/D1677 GHC Trac Issues: #10728
* - fix tests on OpenBSD which requires _DYNAMIC symbolKarel Gardas2015-12-231-1/+2
| | | | | | | | | | | | | Summary: This patch adds _DYNAMIC symbol to the list of OpenBSD symbols. The patch fixes unknown _DYNAMIC symbol runtime linker error caused by recent update of unix library. Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1689
* Fix GHCi segfault in Windows 32bitTamar Christina2015-12-221-6/+2
| | | | | | | | | | | | | | | | | | Summary: Add missing calling convention to function pointer, incorrect `cdecl` calling convention which should be `stdcall` on x86 was causing the stack to be corrupted. When it tried to return from the function the return pointer would be invalid. Test Plan: ./validate Reviewers: austin, erikd, bgamari, thomie Reviewed By: bgamari, thomie Differential Revision: https://phabricator.haskell.org/D1683 GHC Trac Issues: #11234
* Maintain cost-centre stacks in the interpreterSimon Marlow2015-12-217-69/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement phase 1 of expanded FloatingDan Doel2015-12-211-0/+4
| | | | | | | | | | | | | | | | - This part of the proposal is to add log1p, expm1, log1pexp and log1mexp to the Floating class, and export the full Floating class from Numeric Reviewers: ekmett, #core_libraries_committee, bgamari, hvr, austin Reviewed By: ekmett, #core_libraries_committee, bgamari Subscribers: Phyx, RyanGlScott, ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1605 GHC Trac Issues: #11166
* Fix two occurences of `x86_HOST_ARCH`Herbert Valerio Riedel2015-12-191-1/+1
| | | | | | | | | | | | | | | The proper name for the define is `i386_HOST_ARCH` One was introduced back in 2011 via 035b8ebb5405efbcbfd3474821a877add1feca1e / #4914 and the other one more recently via 4905b83a2d448c65ccced385343d4e8124548a3b We may want to add some validation to catch such typos early on... Reviewed By: erikd Differential Revision: https://phabricator.haskell.org/D1664
* Add -Nmax<n> RTS feature (#10728)MarcelineVQ2015-12-191-4/+13
| | | | | | | | | | Added maximum core use based on processors -Nmax<x> chooses the minimum of processor count or x Added documentation. Reviewed By: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D1650
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (Apologies for the size of this patch, I couldn't make a smaller one that was validate-clean and also made sense independently) (Some of this code is derived from GHCJS.) This commit adds support for running interpreted code (for GHCi and TemplateHaskell) in a separate process. The functionality is experimental, so for now it is off by default and enabled by the flag -fexternal-interpreter. Reaosns we want this: * compiling Template Haskell code with -prof does not require building the code without -prof first * when GHC itself is profiled, it can interpret unprofiled code, and the same applies to dynamic linking. We would no longer need to force -dynamic-too with TemplateHaskell, and we can load ordinary objects into a dynamically-linked GHCi (and vice versa). * An unprofiled GHCi can load and run profiled code, which means it can use the stack-trace functionality provided by profiling without taking the performance hit on the compiler that profiling would entail. Amongst other things; see https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details. Notes on the implementation are in Note [Remote GHCi] in the new module compiler/ghci/GHCi.hs. It probably needs more documenting, feel free to suggest things I could elaborate on. Things that are not currently implemented for -fexternal-interpreter: * The GHCi debugger * :set prog, :set args in GHCi * `recover` in Template Haskell * Redirecting stdin/stdout for the external process These are all doable, I just wanted to get to a working validate-clean patch first. I also haven't done any benchmarking yet. I expect there to be slight hit to link times for byte code and some penalty due to having to serialize/deserialize TH syntax, but I don't expect it to be a serious problem. There's also lots of low-hanging fruit in the byte code generator/linker that we could exploit to speed things up. Test Plan: * validate * I've run parts of the test suite with EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th. There are a few failures due to the things not currently implemented (see above). Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1562
* Some more typos in commentsGabor Greif2015-12-141-1/+1
|
* rts: One more Clang-unfriendly CPP usageBen Gamari2015-12-071-3/+3
|
* rts: Remove space before argument list in ASSERTsBen Gamari2015-12-072-49/+49
| | | | | | | | | | Test Plan: Validate Reviewers: austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1569
* Allow to compile OSMem.c when MEM_NORESERVE is not availableHerbert Valerio Riedel2015-12-051-0/+7
| | | | | | | | | | | | On some OSes such as AIX `MEM_NORESERVE` is not available. Since this feature is only needed when the new two-step allocator (see #9706) is enabled we can simply turn this into a runtime error to avoid a larger refactoring of this already quite platform-sensitive code. Reviewed By: bgamari, ezyang Differential Revision: https://phabricator.haskell.org/D1568
* libdw: enable support only on i386 and amd64Sergei Trofimovich2015-12-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently libdw requires per-arch implementation of set_initial_registers() function. Otherwise build fails with linkage error (seen on sparc): rts/dist/build/libHSrts_thr-ghc7.11.20151129.so: undefined reference to `set_initial_registers' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 Converted link-time error to compile-time error, added arch whitelist. Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewers: austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1567
* RTS: Rename InCall.stat struct field to .rstatHerbert Valerio Riedel2015-12-044-10/+10
| | | | | | | | | | | On AIX, C system headers can redirect the token `stat` via #define stat stat64 to provide large-file support. Simply avoiding the use of `stat` as an identifier eschews macro-replacement. Differential Revision: https://phabricator.haskell.org/D1566
* Use Autoconf's AC_USE_SYSTEM_EXTENSIONSHerbert Valerio Riedel2015-12-042-13/+0
| | | | | | | | | | | | | | | | | | | | | | This takes care of setting feature test macros (i.e. let Autoconf decide when those can be set safely) to allow subsequent Autoconf tests to better detect available OS features. This also includes a submodule update of unix which enables the use of `AC_USE_SYSTEM_EXTENSIONS` in there as well. Specifically, this takes care of setting `_GNU_SOURCE` (which allows to remove two occurences where it's set manually) and `_ALL_SOURCE` (which fixes issues on AIX). See also https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Posix-Variants.html for details. At some point we may want to reconsider the purpose of "rts/PosixSource.h" and rely more on Autoconf instead.
* LibdwPool: Use poolTryTakeBen Gamari2015-11-261-1/+18
|
* rts/Pool: Add poolTryTakeBen Gamari2015-11-262-12/+39
|
* rts: Always export Libdw* symbolsBen Gamari2015-11-231-4/+0
| | | | | | | | | | | | | Otherwise we'll get link time failures as `base` always builds `GHC.ExecutionStack`. Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1519
* rts: Add LibdwPool, a pool for libdw sessionsBen Gamari2015-11-234-1/+86
| | | | Differential Revision: https://phabricator.haskell.org/D1198#40948
* rts: Add simple resource poolBen Gamari2015-11-232-0/+234
|
* rts: Expose more libdw symbolsBen Gamari2015-11-233-14/+28
|
* Libdw: Fix initial register collection on i386Ben Gamari2015-11-231-1/+2
| | | | RIP-relative addressing isn't available on i386.
* Libdw: Fix build on 32-bit platformsBen Gamari2015-11-231-5/+6
| | | | | | The casting here is a bit tricky since Dwarf_Addr is always 64-bits. This means we first need to narrow to uintptr_t before casting to/from a pointer for compatibility on 32-bit architectures.
* RtsFlags: Fix const warningBen Gamari2015-11-213-4/+11
| | | | | | | | | | Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1509
* rts: Kill PAPI supportBen Gamari2015-11-1811-652/+15
| | | | | | | | | | | | | | | 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-172-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* RtsFlags: Refactor some of the deeper switchesBen Gamari2015-11-161-199/+236
| | | | | | | | | | | | | | | | | | | This was previously nearly impossible to read; now it's merely difficult. Ideally we would do a more thorough refactoring of the RTS command line parser (#4243) but this is more effort than I have time for at the moment. Test Plan: Try using affected RTS flags Reviewers: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1476 GHC Trac Issues: #4243
* RtsFlags: Clean up stale CPPBen Gamari2015-11-161-4/+1
|
* Implement function-sections for Haskell code, #8405Simon Brenner2015-11-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a flag -split-sections that does similar things to -split-objs, but using sections in single object files instead of relying on the Satanic Splitter and other abominations. This is very similar to the GCC flags -ffunction-sections and -fdata-sections. The --gc-sections linker flag, which allows unused sections to actually be removed, is added to all link commands (if the linker supports it) so that space savings from having base compiled with sections can be realized. Supported both in LLVM and the native code-gen, in theory for all architectures, but really tested on x86 only. In the GHC build, a new SplitSections variable enables -split-sections for relevant parts of the build. Test Plan: validate with both settings of SplitSections Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari Reviewed By: simonmar, thomie, bgamari Subscribers: hsyl20, erikd, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D1242 GHC Trac Issues: #8405
* fix RTS Linker on platforms without SHN_XINDEX supportKarel Gardas2015-11-111-6/+30
| | | | | | | | | | | | | | | Summary: This patch fixes RTS Linker compilation issues on platforms where SHN_XINDEX is not defined. Tested on OpenBSD. When SHN_XINDEX is not defined, the code reverts to the old behavior, that means behavior of the Linker before D1357 which added SHN_XINDEX based functionality. Reviewers: bgamari, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1446
* Add OpenBSD specific RTS symbolsKarel Gardas2015-11-081-0/+9
| | | | | | | | | | | | | This patch adds OpenBSD specific RTS symbols. The patch is taken from the OpenBSD ports tree, provided by the OpenBSD community. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1445
* Allow the GHCi Linker to resolve related dependencies when loading DLLsTamar Christina2015-11-073-19/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-078-40/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Linker: #ifdef cleanupErik de Castro Lopo2015-11-042-45/+14
| | | | | | | | | | | | | Test Plan: - Run tests on x86_64/linux and powerpc/linux - Cross compile rts/Linker.c with the i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc Linux to Windows cross-compilers. Reviewers: bgamari, austin, hvr, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1429
* rts/Hash: Constify HashTable* in lookupHashTableBen Gamari2015-11-033-8/+8
| | | | | | | | This seems like an obvious place to apply `const` Reviewed By: simonmar, austin Differential Revision: https://phabricator.haskell.org/D1416
* get rid of Elf32/Elf64_Section as this is a non-portable Linux-ism.Karel Gardas2015-11-021-3/+1
| | | | | | | | | | | | | | | | Summary: D1357 introduces usage of Elf32_Section/Elf64_Section in RTS linker code. Unfortunately this is a non-portable Linux-ism and such types are not defined anywhere except the Linux-land probably. I've checked Solaris 11.2, Solaris 11.3, FreeBSD 10.1, NetBSD 6.1.5 and OpenBSD current. The fix is easy to use `unsigned short' as this is also an underlying type of those Elf*_Section defines in Linux. Reviewers: olsner, austin, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1419
* rts: Produce stack trace on fatal errorBen Gamari2015-11-011-0/+12
| | | | | | | | | | | | Test Plan: Validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: simonmar, thomie, scpmw Differential Revision: https://phabricator.haskell.org/D1418
* EventLog: Loop fwrite if necessary during flushBen Gamari2015-11-011-10/+12
| | | | | | | | | | | | | | | | | | | | | Previously the eventlog flush code would fail if `fwrite` wrote less than the requested amount. Like all Unix stream I/O operations, however, `fwrite` isn't guaranteed to write the entire buffer. Here we loop as long as `fwrite` succeeds in writing anything. Fixes #11041. Test Plan: Validate with eventlog Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1415 GHC Trac Issues: #11041
* Libdw: Fix symbol namingBen Gamari2015-11-013-46/+47
| | | | RTS convention is to use camel-case.
* Libdw: Remove special treatment for stg_stop_threadBen Gamari2015-11-011-4/+1
| | | | | This is no longer necessary since this symbol can be unwound through with its DWARF information.
* StgStartup: Setup unwinding for stg_stop_threadBen Gamari2015-11-012-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a bit ugly as we need to assume the structure of the C stack as left by StgRun. Nevertheless, it allows us to unwind all the way back to `_start` on my machine. ``` Stack trace: set_initial_registers (rts/Libdw.c:272.0) dwfl_thread_getframes dwfl_getthreads dwfl_getthread_frames libdw_get_backtrace (rts/Libdw.c:243.0) base_GHCziExecutionStack_getStackTrace1_info (libraries/base/GHC/ExecutionStack.hs:43.1) base_GHCziExecutionStack_showStackTrace1_info (libraries/base/GHC/ExecutionStack.hs:47.1) base_GHCziBase_bindIO1_info (libraries/base/GHC/Base.hs:1085.1) base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1) base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1) base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1) base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1) base_GHCziBase_thenIO1_info (libraries/base/GHC/Base.hs:1088.1) stg_catch_frame_info (rts/Exception.cmm:370.1) stg_stop_thread_info (rts/StgStartup.cmm:42.1) scheduleWaitThread (rts/Schedule.c:465.0) hs_main (rts/RtsMain.c:65.0) __libc_start_main (/tmp/buildd/glibc-2.19/csu/libc-start.c:321.0) _start ```
* Linker: More uint64_t to uintptr_t fixesErik de Castro Lopo2015-11-011-2/+2
| | | | | | | | | | | | | | | Need to use `uintptr_t` on PowerPC and possibly other 32 bit architectures. Test Plan: Validate on x86_64 and powerpc Linux Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1412
View Lorry Controller Status