summaryrefslogtreecommitdiff
path: root/rts/LinkerInternals.h
Commit message (Collapse)AuthorAgeFilesLines
* Define MAP_ANONYMOUS on systems that only provide MAP_ANONGracjan Polak2016-12-231-0/+10
| | | | | | | | | | | | Reviewers: simonmar, erikd, austin, bgamari Reviewed By: bgamari Subscribers: gracjan, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D2881 GHC Trac Issues: #13005
* Don't barf() on failures in loadArchive()Ben Gamari2016-12-071-6/+1
| | | | | | | | | | | | | | | | | | | This patch replaces calls to barf() in loadArchive() with proper error handling. Test Plan: GHC CI Reviewers: rwbarton, erikd, hvr, austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Tags: #ghc Differential Revision: https://phabricator.haskell.org/D2652 GHC Trac Issues: #12388
* Use C99's boolBen Gamari2016-11-291-1/+1
| | | | | | | | | | | | Test Plan: Validate on lots of platforms Reviewers: erikd, simonmar, austin Reviewed By: erikd, simonmar Subscribers: michalt, thomie Differential Revision: https://phabricator.haskell.org/D2699
* Fix windows validateTamar Christina2016-11-171-1/+1
| | | | | | | | | | | | | | | | | Summary: mark myindex as inline only and hide it from profilers. Also prevent this function from being used any other way than just for inlining. Test Plan: ./validate Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2715
* Don't use mmap symbols when !RTS_LINKER_USE_MMAPShea Levy2016-11-151-0/+10
| | | | | | | | | | | | | | | | | | | Some usages of symbols from sys/mman.h are guarded by RTS_LINKER_USE_MMAP by C conditionals, not CPP conditionals. Since those branches are dead anyway when !RTS_LINKER_USE_MMAP, we just stub out the relevant symbols rather than increasing CPP branching. Fixes #12839. Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2710 GHC Trac Issues: #12839
* rts: Fix references to UCharBen Gamari2016-11-131-4/+5
| | | | | | | | | | | | Test Plan: Validate on Windows. Reviewers: erikd, austin, simonmar Reviewed By: erikd Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2700
* rts: Fix LoadArchive on OS XBen Gamari2016-11-111-0/+9
|
* rts/linker: Move loadArchive to new source fileBen Gamari2016-11-101-0/+32
| | | | | | | | | | | | | | Test Plan: Validate Reviewers: DemiMarie, austin, simonmar, erikd Reviewed By: DemiMarie Subscribers: Phyx, thomie, hvr Differential Revision: https://phabricator.haskell.org/D2642 GHC Trac Issues: #12388
* linker: Split ELF implementation into separate source fileBen Gamari2016-11-021-0/+12
| | | | | | | | | | | | Test Plan: Validate Reviewers: erikd, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2650
* linker: Split PEi386 implementation into new source fileBen Gamari2016-11-021-115/+3
| | | | | | | | | | | | Test Plan: Validate Reviewers: erikd, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2648
* Shuffle declarations into LinkerInternals.hBen Gamari2016-11-021-0/+32
| | | | | | | | | | | | | | Summary: These will be needed across source files shortly. Test Plan: Validate Reviewers: erikd, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2647
* linker: Move mmapForLinker declaration into LinkerInternals.hBen Gamari2016-11-021-1/+5
| | | | | | | | | | | | Test Plan: Validate Reviewers: simonmar, erikd, austin Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2645
* linker: Shuffle configuration into LinkerInternals.hBen Gamari2016-11-021-0/+24
| | | | | | | | | | | | Test Plan: Validate Reviewers: erikd, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2644
* Revert "rts/linker: Move loadArchive to new source file"Matthew Pickering2016-10-271-7/+0
| | | | This reverts commit 488a9ed3440fe882ae043ba7f44fed4e84e679ce.
* rts/linker: Move loadArchive to new source fileBen Gamari2016-10-261-0/+7
| | | | | | | | | | | | | | Test Plan: Validate Reviewers: erikd, simonmar, austin, DemiMarie Reviewed By: erikd, simonmar, DemiMarie Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D2615 GHC Trac Issues: #12388
* Remove unused oc->isImportLib (#12230)Simon Marlow2016-07-011-5/+0
| | | | | | | | | | | | | | | | | | | | Summary: This field is never set, but it was being tested and used to decide whether to resolve an object or not. This caused non-deterministic crashes when using the RTS linker (see #12230). I suspect this is not the correct fix, but putting it up so that Phyx can tell us what the right fix should be. Test Plan: validate Reviewers: austin, Phyx, bgamari, erikd Subscribers: erikd, thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2371 GHC Trac Issues: #12230
* Fix incorrect calculated relocations on Windows x86_64Tamar Christina2016-06-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: See #12031 for analysis, but essentially what happens is: To sum up the issue, the reason this seems to go wrong is because of how we initialize the `.bss` section for Windows in the runtime linker. The first issue is where we calculate the zero space for the section: ``` zspace = stgCallocBytes(1, bss_sz, "ocGetNames_PEi386(anonymous bss)"); sectab_i->PointerToRawData = ((UChar*)zspace) - ((UChar*)(oc->image)); ``` Where ``` UInt32 PointerToRawData; ``` This means we're stuffing a `64-bit` value into a `32-bit` one. Also `zspace` can be larger than `oc->image`. In which case it'll overflow and then get truncated in the cast. The address of a value in the `.bss` section is then calculated as: ``` addr = ((UChar*)(oc->image)) + (sectabent->PointerToRawData + symtab_i->Value); ``` If it does truncate then this calculation won't be correct (which is what is happening). We then later use the value of `addr` as the `S` (Symbol) value for the relocations ``` S = (size_t) lookupSymbol_( (char*)symbol ); ``` Now the majority of the relocations are `R_X86_64_PC32` etc. e.g. They are guaranteed to fit in a `32-bit` value. The `R_X86_64_64` introduced for these pseudo-relocations so they can use the full `48-bit` addressing space isn't as lucky. As for why it sometimes work has to do on whether the value is truncated or not. `PointerToRawData` can't be changed because it's size is fixed by the PE specification. Instead just like with the other platforms, we now use `section` on Windows as well. This gives us a `start` parameter of type `void*` which solves the issue. This refactors the code to use `section.start` and to fix the issues. Test Plan: ./validate and new test added T12031 Reviewers: RyanGlScott, erikd, bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2316 GHC Trac Issues: #12031, #11317
* Refactored SymbolInfo to lower memory usage in RTSTamar Christina2016-06-031-16/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously as part of #11223 a new struct `SymbolInfo` was introduced to keep track it the weak symbol status of a symbol. This structure also kept a copy of the calculated address of the symbol which turns out was useful in ignoring non-weak zero-valued symbols. The information was kept in an array so it means for every symbol two extra bytes were kept even though the vast majority of symbols are non-weak and non-zero valued. This changes the array into a sparse map keeping this information only for the symbols that are weak or zero-valued. This allows for a reduction in the amount of information needed to be kept while giving up a small (negligable) hit in performance as this information now has to be looked up in hashmaps. Test Plan: ./validate on all platforms that use the runtime linker. For unix platforms please ensure `DYNAMIC_GHC_PROGRAMS=NO` is added to your validate file. Reviewers: simonmar, austin, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2184 GHC Trac Issues: #11816
* Add Windows import library support to the Runtime LinkerTamar Christina2016-04-171-1/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Import libraries are files ending in `.dll.a` and `.lib` depending on which compiler creates them (GCC, vs MSVC). Import Libraries are standard `archive` files that contain object files. These object files can have two different formats: 1) The normal COFF Object format for object files (contains all ascii data and very little program code, so do not try to execute.) 2) "short import" format which just contains a symbol name and the dll in which the symbol can be found. Import Libraries are useful for two things: 1) Allowing applications that don't support dynamic linking to link against the import lib (non-short format) which then makes calls into the DLL by loading it at runtime. 2) Allow linking of mutually recursive dlls. if `A.DLL` requires `B.DLL` and vice versa, import libs can be used to break the cycle as they can be created from the expected exports of the DLLs. A side effect of having these two capabilities is that Import libs are often used to hide specific versions of DLLs behind a non-versioned import lib. e.g. GCC_S.a (non-conventional import lib) will point to the correct `libGCC` DLL. With this support Windows Haskell files can now just link to `-lGCC_S` and not have to worry about what the actual name of libGCC is. Also third party libraries such as `icuuc` use import libs to forward to versioned DLLs. e.g. `icuuc.lib` points to `icuuc51.dll` etc. Test Plan: ./validate Two new tests added T11072gcc T11072msvc Two binary files have been added to the test folder because the "short" import library format doesn't seem to be creatable via `dlltool` and requires Microsoft's `lib.exe`. Reviewers: bgamari, RyanGlScott, erikd, goldfire, austin, hvr Reviewed By: RyanGlScott, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1696 GHC Trac Issues: #11072
* Linker: Fix signedness mismatchBen Gamari2016-04-151-1/+1
| | | | | | | | | | | | | | Test Plan: Validate on OS X Reviewers: erikd, austin, Phyx Reviewed By: austin, Phyx Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2110 GHC Trac Issues: #11828
* Change runtime linker to perform lazy loading of symbols/sectionsTamar Christina2016-04-111-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Runtime Linker is currently eagerly loading all object files on all platforms which do not use the system linker for `GHCi`. The problem with this approach is that it requires all symbols to be found. Even those of functions never used/called. This makes the number of libraries required to link things like `mingwex` quite high. To work around this the `rts` was relying on a trick. It itself was compiled with `MingW64-w`'s `GCC`. So it was already linked against `mingwex`. As such, it re-exported the symbols from itself. While this worked it made it impossible to link against `mingwex` in user libraries. And with this means no `C99` code could ever run in `GHCi` on Windows without having the required symbols re-exported from the rts. Consequently this rules out a large number of packages on Windows. SDL2, HMatrix etc. After talking with @rwbarton I have taken the approach of loading entire object files when a symbol is needed instead of doing the dependency tracking on a per symbol basis. This is a lot less fragile and a lot less complicated to implement. The changes come down to the following steps: 1) modify the linker to and introduce a new state for ObjectCode: `Needed`. A Needed object is one that is required for the linking to succeed. The initial set consists of all Object files passed as arguments to the link. 2) Change `ObjectCode`'s to be indexed but not initialized or resolved. This means we know where we would load the symbols, but haven't actually done so. 3) Mark any `ObjectCode` belonging to `.o` passed as argument as required: ObjectState `NEEDED`. 4) During `Resolve` object calls, mark all `ObjectCode` containing the required symbols as `NEEDED` 5) During `lookupSymbol` lookups, (which is called from `linkExpr` and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded `ObjectCode` then load the `ObjectCode` on demand and return the address of the symbol. Otherwise produce an unresolved symbols error as expected. 6) On `unloadObj` we then change the state of the object and remove it's symbols from the `reqSymHash` table so it can be reloaded. This change affects all platforms and OSes which use the runtime linker. It seems there are no real perf tests for `GHCi`, but performance shouldn't be impacted much. We gain a lot of time not loading all `obj` files, and we lose some time in `lookupSymbol` when we're finding sections that have to be loaded. The actual finding itself is O(1) (Assuming the hashtnl is perfect) It also consumes slighly more memory as instead of storing just the address of a symbol I also store some other information, like if the symbol is weak or not. This change will break any packages relying on renamed POSIX functions that were re-named and re-exported by the rts. Any packages following the proper naming for functions as found on MSDN will work fine. Test Plan: ./validate on all platforms which use the Runtime linker. Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr Reviewed By: erikd Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar, rwbarton, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1805 GHC Trac Issues: #11223
* Linker: #ifdef cleanupErik de Castro Lopo2015-11-041-5/+3
| | | | | | | | | | | | | 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
* ELF/x86_64: map object file sections separately into the low 2GBSimon Marlow2015-10-151-9/+31
| | | | | | | | | | | | | | | | | | | | | | | On 64-bit ELF we need to link object files into the low 2GB due to the small memory model. Previously we would map the entire object file using MAP_32BIT, but the object file can consist of 75% or more symbols, which only need to be present during linking, so this is wasteful. In our particular application, we're already running out of space here. This patch changes the way we load object files on ELF platforms so that the object is first mapped above the 2GB boundary, parsed, and then the important sections are re-mapped into the low 2GB area. Test Plan: validate (also needs testing on OS X & Windows, preferably 32 & 64 bit) Reviewers: Phyx, trommler, bgamari, austin Subscribers: hsyl20, thomie, bgamari Differential Revision: https://phabricator.haskell.org/D975
* Allow the linker to run concurrently with the GCSimon Marlow2015-01-131-0/+1
|
* Revert "Revert "Make the linker API thread-safe""Simon Marlow2014-12-051-0/+4
| | | | | | | Also includes a fix for the segfaults on Windows caused by the original version of this patch. This reverts commit 4b51194df4090d984f02c12128e868077660fb8b.
* Revert "Make the linker API thread-safe"Simon Peyton Jones2014-12-021-4/+0
| | | | | | | | | | | | | | | | This reverts commit b5e8b3b162b3ff15ae6caf1afc659565365f54a8. 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.
* Make the linker API thread-safeSimon Marlow2014-11-281-0/+4
| | | | | | We used to be able to rely on the client to use the API in a single-threaded way, but now that the GC calls into the linker to unload objects this isn't a safe assumption.
* Revert "rts: add Emacs 'Local Variables' to every .c file"Simon Marlow2014-09-291-8/+0
| | | | This reverts commit 39b5c1cbd8950755de400933cecca7b8deb4ffcd.
* rts: add Emacs 'Local Variables' to every .c fileAustin Seipp2014-07-281-0/+8
| | | | | | | | This will hopefully help ensure some basic consistency in the forward by overriding buffer variables. In particular, it sets the wrap length, the offset to 4, and turns off tabs. Signed-off-by: Austin Seipp <austin@well-typed.com>
* Fix linker_unload now that we are running constructors in the linker (#8291)Simon Marlow2013-09-231-0/+13
| | | | | | | 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().
* Implement .init/.init_array support for ELF.Edward Z. Yang2013-09-131-0/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
* Really unload object code when it is safe to do so (#8039)Simon Marlow2013-08-221-1/+11
| | | | | | | | | | | | | | | The next major GC after an unloadObj() will do a traversal of the heap to determine whether the object code can be removed from memory or not. We'll keep doing these until it is safe to remove the object code. In my experiments with GHCi, the objects get unloaded immediately, which is a good sign: we're not accidentally holding on to any references anywhere in the GHC data structures. Changes relative to the patch earlier posted on the ticket: - fix two memory leaks discovered with Valgrind, after testing with tests/rts/linker_unload.c
* Add linker support for ELF on ARMBen Gamari2012-03-301-2/+4
| | | | | | | | | | | | | | | | | | | | | | | Add support for ELF objects on ARM to the runtime linker. While the list of relocation types in the "ELF for the ARM Architecture" specification spans four pages, we thankfully only see a handful of these in the wild. Thus, at the moment we only support the following .rel relocation types, * R_ARM_ABS32 * R_ARM_TARGET1 * R_ARM_REL32 * R_ARM_CALL * R_ARM_JUMP24 * R_ARM_MOVT_ABS * R_ARM_MOVW_ABS_NC * R_ARM_THM_CALL * R_ARM_THM_JUMP24 * R_ARM_THM_MOVT_ABS * R_ARM_THM_MOVW_ABS_NC * R_ARM_THM_JUMP8 * R_ARM_THM_JUMP11 Signed-off-by: Ben Gamari <bgamari.foss@gmail.com>
* Make the RTS linker API use wide-char pathnames on Windows (#5697)Simon Marlow2012-01-091-1/+1
| | | | | 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.
* New member "archiveMemberName" for struct _ObjectCodepho@cielonegro.org2010-09-271-0/+11
| | | | | struct _ObjectCode should be able to retain the name of archive members. Though currently the only use of those names are for debugging outputs.
* Change some TARGET tests to HOST tests in the RTSIan Lynagh2010-07-131-1/+1
| | | | Which was being used seemed to be random
* FIX #2615 (linker scripts in .so files)howard_b_golden@yahoo.com2009-12-161-0/+2
| | | | | | | | This patch does not apply to Windows. It only applies to systems with ELF binaries. This is a patch to rts/Linker.c to recognize linker scripts in .so files and find the real target .so shared library for loading.
* 2nd try: remove lochash, it isn't needed (now)Simon Marlow2008-08-041-3/+0
|
* UNDO: FIX #2375: remove oc->lochash completely, it apparently isn't usedSimon Marlow2008-08-041-0/+3
|
* FIX #2375: remove oc->lochash completely, it apparently isn't usedSimon Marlow2008-07-301-3/+0
|
* Darwin/x86_64 linker supportwolfgang.thaller@gmx.net2007-04-121-10/+15
| | | | Initial support for loading x86_64 Mach-O files
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+110
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.
View Lorry Controller Status