summaryrefslogtreecommitdiff
path: root/rts/RtsSymbols.c
Commit message (Collapse)AuthorAgeFilesLines
* - 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
* Maintain cost-centre stacks in the interpreterSimon Marlow2015-12-211-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
* 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
* 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-231-1/+4
| | | | Differential Revision: https://phabricator.haskell.org/D1198#40948
* rts: Expose more libdw symbolsBen Gamari2015-11-231-0/+10
|
* Fix archive loading on Windows by the runtime loaderTamar Christina2015-11-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-071-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove cygwin32_HOST_OS #ifdefsErik de Castro Lopo2015-10-261-89/+1
| | | | | | | | | | | | | | | | | Build system support for Cygwin was removed in b6be81b841. Test Plan: - Validate on x86_64/linux - Cross-compile rts/RtsSymbols.c and rts/Linker.c to Windows using the i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc cross compilers. Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1371
* rts/RtsSymbols.c: Fix Windows buildErik de Castro Lopo2015-10-251-0/+8
| | | | | | | | | | | | | Test Plan: - Build whole of GHC on Linux. - Cross-compile rts/RtsSymbols.c and rts/Linker.c to Windows using the i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc cross compilers. Reviewers: bgamari, awson, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1365
* rts/Linker.c: Split RTS symbols out into separate fileErik de Castro Lopo2015-10-241-0/+1188
Pull the RtsSymbolVal typedef and rtsSyms[] array out into a separate header and C file. No change in functionality. Test Plan: validate Reviewers: simonmar, austin, bgamari Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D1362
View Lorry Controller Status