summaryrefslogtreecommitdiff
path: root/includes/rts/Linker.h
Commit message (Collapse)AuthorAgeFilesLines
* Move `/includes` to `/rts/include`, sort per package betterJohn Ericson2021-08-091-114/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | In order to make the packages in this repo "reinstallable", we need to associate source code with a specific packages. Having a top level `/includes` dir that mixes concerns (which packages' includes?) gets in the way of this. To start, I have moved everything to `rts/`, which is mostly correct. There are a few things however that really don't belong in the rts (like the generated constants haskell type, `CodeGen.Platform.h`). Those needed to be manually adjusted. Things of note: - No symlinking for sake of windows, so we hard-link at configure time. - `CodeGen.Platform.h` no longer as `.hs` extension (in addition to being moved to `compiler/`) so as not to confuse anyone, since it is next to Haskell files. - Blanket `-Iincludes` is gone in both build systems, include paths now more strictly respect per-package dependencies. - `deriveConstants` has been taught to not require a `--target-os` flag when generating the platform-agnostic Haskell type. Make takes advantage of this, but Hadrian has yet to.
* Add loadNativeObj and unloadNativeObjRay Shih2020-11-111-0/+13
| | | | | | | | | | | | | | | | | | | (This change is originally written by niteria) This adds two functions: * `loadNativeObj` * `unloadNativeObj` and implements them for Linux. They are useful if you want to load a shared object with Haskell code using the system linker and have GHC call dlclose() after the code is no longer referenced from the heap. Using the system linker allows you to load the shared object above outside the low-mem region. It also loads the DWARF sections in a way that `perf` understands. `dl_iterate_phdr` is what makes this implementation Linux specific.
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* [RTS] Add getObjectLoadStatusBartosz Nitka2017-09-181-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | This adds a function to the RTS linker API which lets the user check the status of dynamically linked objects. It was initially proposed by @afarmer in D2068. It's useful for testing the linker and also for detecting retention problems in production. It takes a path, because it's easier to use path as key instead of producing some stable handle. It returns an enum instead of bool, because I see no reason for destroying information. All the complexity is already out in the open, so there's nothing to save the users from. Test Plan: ./validate Reviewers: simonmar, Phyx, bgamari, austin, erikd Reviewed By: Phyx, bgamari Subscribers: rwbarton, afarmer, thomie Differential Revision: https://phabricator.haskell.org/D3963
* cpp: Use #pragma once instead of #ifndef guardsBen Gamari2017-04-231-4/+1
| | | | | | | | | | | | | | This both says what we mean and silences a bunch of spurious CPP linting warnings. This pragma is supported by all CPP implementations which we support. Reviewers: austin, erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3482
* 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
* 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
* 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.
* Make the linker more robust to errorsSimon Marlow2014-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: When linking fails because there was a problem with the supplied object file, then we should not barf() or exit, we should emit a suitable error message and return an error code to the caller. We should also free all memory that might have been allocated during linking, and generally not do any damage. This patch fixes most common instances of this problem. Test Plan: validate Reviewers: rwbarton, austin, ezyang Reviewed By: ezyang Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D294
* Grammar in commentsGabor Greif2013-11-221-1/+1
|
* Allow the linker to be used without retaining CAFs unconditionallySimon Marlow2013-11-211-2/+19
| | | | | | | | | This creates a new C API: initLinker_ (int retain_cafs) The old initLinker() was left as-is for backwards compatibility. See documentation in Linker.h.
* Linker.c: remove stablehash, which is no longer usedTakano Akio2013-10-251-3/+0
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-1/+1
|
* Fix linker_unload now that we are running constructors in the linker (#8291)Simon Marlow2013-09-231-0/+3
| | | | | | | See also #5435. Now we have to remember the the StablePtrs that get created by the module initializer so that we can free them again in unloadObj().
* Fix printf formats for pathchar on Windows (where it's wchar_t, not char)Simon Marlow2013-09-041-0/+2
|
* Make the RTS linker API use wide-char pathnames on Windows (#5697)Simon Marlow2012-01-091-6/+12
| | | | | I haven't been able to test whether this works or not due to #5754, but at least it doesn't appear to break anything.
* Implement archive loading for ghciIan Lynagh2010-09-201-0/+3
|
* Tidy up file headers and copyrights; point to the wiki for docsSimon Marlow2009-08-251-1/+6
| | | | | | | I've updated the wiki page about the RTS headers http://hackage.haskell.org/trac/ghc/wiki/Commentary/SourceTree/Includes to reflect the new layout and explain some of the rationale. All the header files now point to this page.
* RTS tidyup sweep, first phaseSimon Marlow2009-08-021-0/+36
The first phase of this tidyup is focussed on the header files, and in particular making sure we are exposinng publicly exactly what we need to, and no more. - Rts.h now includes everything that the RTS exposes publicly, rather than a random subset of it. - Most of the public header files have moved into subdirectories, and many of them have been renamed. But clients should not need to include any of the other headers directly, just #include the main public headers: Rts.h, HsFFI.h, RtsAPI.h. - All the headers needed for via-C compilation have moved into the stg subdirectory, which is self-contained. Most of the headers for the rest of the RTS APIs have moved into the rts subdirectory. - I left MachDeps.h where it is, because it is so widely used in Haskell code. - I left a deprecated stub for RtsFlags.h in place. The flag structures are now exposed by Rts.h. - Various internal APIs are no longer exposed by public header files. - Various bits of dead code and declarations have been removed - More gcc warnings are turned on, and the RTS code is more warning-clean. - More source files #include "PosixSource.h", and hence only use standard POSIX (1003.1c-1995) interfaces. There is a lot more tidying up still to do, this is just the first pass. I also intend to standardise the names for external RTS APIs (e.g use the rts_ prefix consistently), and declare the internal APIs as hidden for shared libraries.
View Lorry Controller Status