summaryrefslogtreecommitdiff
path: root/rts/Linker.c
Commit message (Collapse)AuthorAgeFilesLines
* [linker] Adds void printLoadedObjects(void);wip/angerman/print-loaded-objectsMoritz Angermann2020-06-041-2/+28
| | | | | | This allows us to dump in-memory object code locations for debugging. Fixup printLoadedObjects prototype
* Linker.c: initialize n_symbols of ObjectCode with other fieldsÖmer Sinan Ağacan2020-05-081-0/+1
|
* Fix typos, via a Levenshtein-style correctorBrian Wignall2020-01-041-1/+1
|
* rts: Specialize hashing at call site rather than in struct.Crazycolorz52019-12-111-6/+6
| | | | | | | | | | | | | | | | Separate word and string hash tables on the type level, and do not store the hashing function. Thus when a different hash function is desire it is provided upon accessing the table. This is worst case the same as before the change, and in the majority of cases is better. Also mark the functions for aggressive inlining to improve performance. {F1686506} Reviewers: bgamari, erikd, simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13165 Differential Revision: https://phabricator.haskell.org/D4889
* rts/linker: Ensure that code isn't writableBen Gamari2019-11-041-7/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | For many years the linker would simply map all of its memory with PROT_READ|PROT_WRITE|PROT_EXEC. However operating systems have been becoming increasingly reluctant to accept this practice (e.g. #17353 and #12657) and for good reason: writable code is ripe for exploitation. Consequently mmapForLinker now maps its memory with PROT_READ|PROT_WRITE. After the linker has finished filling/relocating the mapping it must then call mmapForLinkerMarkExecutable on the sections of the mapping which contain executable code. Moreover, to make all of this possible it was necessary to redesign the m32 allocator. First, we gave (in an earlier commit) each ObjectCode its own m32_allocator. This was necessary since code loading and symbol resolution/relocation are currently interleaved, meaning that it is not possible to enforce W^X when symbols from different objects reside in the same page. We then redesigned the m32 allocator to take advantage of the fact that all of the pages allocated with the allocator die at the same time (namely, when the owning ObjectCode is unloaded). This makes a number of things simpler (e.g. no more page reference counting; the interface provided by the allocator for freeing is simpler). See Note [M32 Allocator] for details.
* rts: Make m32 allocator per-ObjectCodeBen Gamari2019-11-011-3/+7
| | | | | | | | | | | | | | | | | MacOS Catalina is finally going to force our hand in forbidden writable exeutable mappings. Unfortunately, this is quite incompatible with the current global m32 allocator, which mixes symbols from various objects in a single page. The problem here is that some of these symbols may not yet be resolved (e.g. had relocations performed) as this happens lazily (and therefore we can't yet make the section read-only and therefore executable). The easiest way around this is to simply create one m32 allocator per ObjectCode. This may slightly increase fragmentation for short-running programs but I suspect will actually improve fragmentation for programs doing lots of loading/unloading since we can always free all of the pages allocated to an object when it is unloaded (although this ability will only be implemented in a later patch).
* mmap: Factor out protection flagsBen Gamari2019-11-011-4/+3
|
* Add new debug flag -DZTobias Guggenmos2019-10-031-2/+2
| | | | Zeros heap memory after gc freed it.
* rts: Rename the nondescript initProfiling2 to refreshProfilingCCSsDaniel Gröber2019-07-161-3/+2
|
* Fix #16525: ObjectCode freed wrongly because of lack of info header checkPhuong Trinh2019-06-131-0/+6
| | | | | | | `checkUnload` currently doesn't check the info header of static objects. Thus, it may free an `ObjectCode` struct wrongly even if there's still a live static object whose info header lies in a mapped section of that `ObjectCode`. This fixes the issue by adding an appropriate check.
* rts/linker: Mmap into low memory on AArch64Ben Gamari2019-06-111-13/+22
| | | | | This extends mmapForLinker to use the same low-memory mapping strategy used on x86_64 on AArch64. See #16784.
* Address some todos and fixmesArtem Pyanykh2019-03-201-0/+1
|
* Use segments for section layoutArtem Pyanykh2019-03-201-0/+50
|
* Adjust section placement and relocation logic for Mach-OArtem Pyanykh2019-03-201-3/+7
| | | | | | | | | | | | | | 1. Place each section on a separate page to ensure required alignment (wastes lots ot space, needs to be improved). 2. Unwire relocation logic from macho sections (the most fiddly part is adjusting internal relocations). Other todos: 0. Add a test for section alignment. 1. Investigate 32bit relocations! 2. Fix memory leak in ZEROPAGE section allocation. 3. Fix creating redundant jump islands for GOT. 4. Investigate more compact section placement.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-2/+2
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Drop support for i386 and PowerPC in MachO linkerArtem Pyanykh2019-02-221-3/+1
| | | | | | Some code is broken, there are no CI targets (so not obvious how to test), and no one seems to have built GHC for any of the above platforms in years.
* Allocate bss section within proper range of other sectionsZejun Wu2019-01-301-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This re-applies {D5195} and {D5235}, they were reverted as part of diff stack to unbreak i386. The proper fix is done in {D5289}. Allocate bss section within proper range of other sections: * when `+RTS -xp` is passed, allocate it contiguously as we did for jump islands * when we mmap the code to lower 2Gb, we should allocate bss section there too Test Plan: 1. `./validate` 2. with ``` DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO ``` `TEST="T15729" make test` passed in both linux (both i386 and x86_64) and macos. 3. Also test in a use case where we used to encouter error like: ``` ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) = b90282ba ``` and now, everything works fine. Reviewers: simonmar, bgamari, angerman, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15729 Differential Revision: https://phabricator.haskell.org/D5290
* Add a RTS option -xp to load PIC object anywhere in address spaceZejun Wu2019-01-301-41/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This re-applies {D5195} with fixes for i386: * Fix unused label warnings, see {D5230} or {D5273} * Fix a silly bug introduced by moving `#if` {P190} Add a RTS option -xp to load PIC object anywhere in address space. We do this by relaxing the requirement of <0x80000000 result of `mmapForLinker` and implying USE_CONTIGUOUS_MMAP. We also need to change calls to `ocInit` and `ocGetNames` to avoid dangling pointers when the address of `oc->image` is changed by `ocAllocateSymbolExtra`. Test Plan: See {D5195}, also test under i386: ``` $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ cd testsuite/tests/th/ && make test ... ``` will run `./validate` on stacked diff. Reviewers: simonmar, bgamari, alpmestan, trommler, hvr, erikd Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5289
* Revert "Batch merge"Ben Gamari2019-01-301-47/+43
| | | | This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
* Batch mergeBen Gamari2019-01-301-43/+47
|
* Extend linker-script workaround to work with musl libcSamuel Holland2019-01-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC has code to handle unsuffixed .so files that are linker scripts pointing to the real shared library. The detection is done by parsing the result of `dlerror()` after calling `dlopen()` and looking for certain error strings. On musl libc, the error message is "Exec format error", which happens to be `strerror(ENOEXEC)`: ``` $ cat tmp.c #include <dlfcn.h> #include <stdio.h> int main(void) { dlopen("libz.so", RTLD_NOW | RTLD_GLOBAL); puts(dlerror()); return 0; } $ gcc -o tmp tmp.c $ ./tmp Error loading shared library libz.so: Exec format error $ ``` This change fixes the workaround to also work on musl libc. Link: https://phabricator.haskell.org/D5474
* linker: store entire link map and use it.Tamar Christina2018-12-041-10/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes a corner case in which we have seen the symbol multiple times in different static libraries, but due to a depencency we end up loading the symbol from a library other than the first one. Previously the runtime linker would only track symbols from the first library and did not store the full link map. In this case it was unable to find the address for the symbols in the second library during delay loading. This change stores the address of all symbols seen so a full link map is generated, such that when we make a different decision later than what was expected we're able to still correctly load the library. Test Plan: ./validate, new testcase T15894 Reviewers: angerman, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15894 Differential Revision: https://phabricator.haskell.org/D5353
* Revert "Add a RTS option -xp to load PIC object anywhere in address space"Ben Gamari2018-10-301-39/+41
| | | | This reverts commit 5403a8636fe82f971234873564f3a05393b89b7a.
* Revert "Allocate bss section within proper range of other sections"Ben Gamari2018-10-301-12/+10
| | | | | | | | This reverts commit e019ec94f12268dd92ea5d5204e9e57e7ebf10ca. This sadly breaks the external interpreter on i386. For instance, see https://circleci.com/gh/ghc/ghc/10925.
* Allocate bss section within proper range of other sectionsZejun Wu2018-10-151-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allocate bss section within proper range of other sections: * when `+RTS -xp` is passed, allocate it contiguously as we did for jump islands * when we mmap the code to lower 2Gb, we should allocate bss section there too This depends on {D5195} Test Plan: 1. `./validate` 2. with ``` DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO ``` `TEST="T15729" make test` passed in both linux and macos. 3. Also test in a use case where we used to encouter error like: ``` ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) = b90282ba ``` and now, everything works fine. Reviewers: simonmar, bgamari, angerman, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15729 Differential Revision: https://phabricator.haskell.org/D5219
* Add a RTS option -xp to load PIC object anywhere in address spaceZejun Wu2018-10-151-41/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a RTS option -xp to load PIC object anywhere in address space. We do this by relaxing the requirement of <0x80000000 result of `mmapForLinker` and implying USE_CONTIGUOUS_MMAP. We also need to change calls to `ocInit` and `ocGetNames` to avoid dangling pointers when the address of `oc->image` is changed by `ocAllocateSymbolExtra`. Test Plan: ``` $ uname -a Linux localhost 4.18.8-arch1-1-ARCH #1 SMP PREEMPT Sat Sep 15 20:34:48 UTC 2018 x86_64 GNU/Linux $ cat mk/build.mk DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO GhcRTSWays += thr_debug EXTRA_HC_OPTS += -debug WAY_p_HC_OPTS += -fPIC -fexternal-dynamic-refs $ inplace/bin/ghc-stage2 --interactive -prof +RTS -xp GHCi, version 8.7.20180928: http://www.haskell.org/ghc/ :? for help ghc-stage2: R_X86_64_32 relocation out of range: ghczmprim_GHCziTypes_ZMZN_closure = 7f690bffab59 Recompile /data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim -0.5.3.o with -fPIC -fexternal-dynamic-refs. ghc-stage2: unable to load package `ghc-prim-0.5.3' $ strace -f -e open,mmap inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter -opti+RTS -opti-xp ... [pid 1355283] open("/data/users/watashi/ghc/libraries/base/dist-install/build/libHSbas e-4.12.0.0_p.a", O_RDONLY) = 14 [pid 1355283] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a84842000 [pid 1355283] open("/data/users/watashi/ghc/libraries/base/dist-install/build/libHSbas e-4.12.0.0_p.a", O_RDONLY) = 14 [pid 1355283] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a84676000 ... Prelude> System.Posix.Process.getProcessID ... [pid 1355283] open("/data/users/watashi/ghc/libraries/unix/dist-install/build/libHSuni x-2.7.2.2_p.a", O_RDONLY) = 14 [pid 1355283] mmap(NULL, 45056, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a67d60000 [pid 1355283] open("/data/users/watashi/ghc/libraries/unix/dist-install/build/libHSuni x-2.7.2.2_p.a", O_RDONLY) = 14 [pid 1355283] mmap(NULL, 57344, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a67d52000 ... ``` ``` $ uname -a Darwin watashis-iMac.local 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64 $ mv /Users/watashi/gao/ghc/libraries/integer-gmp/dist-install/build/HSintege r-gmp-1.0.2.0.o{,._DISABLE_GHC_ISSUE_15105} $ inplace/bin/ghc-stage2 --interactive +RTS -xp GHCi, version 8.7.20181003: http://www.haskell.org/ghc/ :? for help Prelude> System.Posix.Process.getProcessID 42791 Prelude> Data.Set.fromList [1 .. 10] fromList [1,2,3,4,5,6,7,8,9,10] Prelude> Leaving GHCi. $ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter GHCi, version 8.7.20181003: http://www.haskell.org/ghc/ :? for help Prelude> System.Posix.Process.getProcessID 42806 Prelude> Data.Set.fromList [1 .. 10] fromList [1,2,3,4,5,6,7,8,9,10] Prelude> Leaving GHCi. ``` Also test with something that used to hit the 2Gb limit and it loads and runs without problem. Reviewers: simonmar, bgamari, angerman, Phyx, hvr, erikd Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5195
* Fix PE linker wibblesTamar Christina2018-10-041-0/+6
| | | | | | | | | | | | | | | | | Fix some various issues that popped up because the linker now doesn't load import libraries for longer than it needs to. These are all use after free issues. Test Plan: ./validate Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: simonpj, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5175
* Updated PE linker, section alignment and cleanup.Tamar Christina2018-09-171-29/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is to address a couple of short comings of the PE linker. The first thing it does is properly honor section alignments, so SSE code will work reliably. While doing this I've also changed how it reads and stores ObjectFile information. Previously the entire object file was read in and treated as one blob, including headers, symbol tables etc. Now the ObjectFile is read in but stored in chunks, tables go into a temporary info struct and code/data into a new private heap. This allows me to free all meta data once we're done relocating. Which means we can reclaim this memory. As I've mentioned above I've also moved from using VirtualAlloc to HeapAlloc. The reason is VirtualAlloc is meant to be used for more low level memory allocation, it's very fast because it can only allocate whole blocks, (64k) by default, and the memory must be paged (4k) aligned. So when you ask for e.g. 30k of memory, you're given a whole block where 34k will be wasted memory. Nothing else can ever access that untill you free the 30k. One downside of HeapAlloc is that you're not in control of how the heap grows, and heap memory is always committed. So it's harder to tell how much we're actually using now. Another big upside of splitting off the ObjectCode tables to info structs is that I can adjust them, so that later addressings can just use array subscripts to index into them. This simplifies the code a lot and a lot of complicated casts and indexing can be removed. Leaving less and more simple code. This patch doesn't fix the memprotection but it doesn't regress it either. It does however make the next changes smaller and fixes the alignments. Test Plan: ./validate , new test T13617 Reviewers: bgamari, erikd, simonmar, hvr, angerman Reviewed By: angerman Subscribers: nickkuk, carter, RyanGlScott, rwbarton, thomie GHC Trac Issues: #13617 Differential Revision: https://phabricator.haskell.org/D3915
* Finish stable splitDavid Feuer2018-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Long ago, the stable name table and stable pointer tables were one. Now, they are separate, and have significantly different implementations. I believe the time has come to finish the split that began in #7674. * Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`. * Give each table its own mutex. * Add FFI functions `hs_lock_stable_ptr_table` and `hs_unlock_stable_ptr_table` and document them. These are intended to replace the previously undocumented `hs_lock_stable_tables` and `hs_lock_stable_tables`, which are now documented as deprecated synonyms. * Make `eqStableName#` use pointer equality instead of unnecessarily comparing stable name table indices. Reviewers: simonmar, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15555 Differential Revision: https://phabricator.haskell.org/D5084
* Remove MAX_PATH restrictions from RTS, I/O manager and various utilitiesTamar Christina2018-03-311-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This shims out fopen and sopen so that they use modern APIs under the hood along with namespaced paths. This lifts the MAX_PATH restrictions from Haskell programs and makes the new limit ~32k. There are only some slight caveats that have been documented. Some utilities have not been upgraded such as lndir, since all these things are different cabal packages I have been forced to copy the source in different places which is less than ideal. But it's the only way to keep sdist working. Test Plan: ./validate Reviewers: hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #10822 Differential Revision: https://phabricator.haskell.org/D4416
* Add stack traces on crashes on WindowsTamar Christina2017-10-221-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the ability to generate stack traces on crashes for Windows. When running in the interpreter this attempts to use symbol information from the interpreter and information we know about the loaded object files to resolve addresses to symbols. When running compiled it doesn't have this information and then defaults to using symbol information from PDB files. Which for now means only files compiled with ICC or MSVC will show traces compiled. But I have a future patch that may address this shortcoming. Also since I don't know how to walk a pure haskell stack, I can for now only show the last entry. I'm hoping to figure out how Apply.cmm works to be able to walk the stalk and give more entries for pure haskell code. In GHCi ``` $ echo main | inplace/bin/ghc-stage2.exe --interactive ./testsuite/tests/rts/derefnull.hs GHCi, version 8.3.20170830: http://www.haskell.org/ghc/ :? for help Ok, 1 module loaded. Prelude Main> Access violation in generated code when reading 0x0 Attempting to reconstruct a stack trace... Frame Code address * 0x77cde10 0xc370229 E:\..\base\dist-install\build\HSbase-4.10.0.0.o+0x190031 (base_ForeignziStorable_zdfStorableInt4_info+0x3f) ``` and compiled ``` Access violation in generated code when reading 0x0 Attempting to reconstruct a stack trace... Frame Code address * 0xf0dbd0 0x40bb01 E:\..\rts\derefnull.run\derefnull.exe+0xbb01 ``` Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3913
* [RTS] Add getObjectLoadStatusBartosz Nitka2017-09-181-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Properly handle dlerror() message on FreeBSD when linking linker scriptsGleb Popov2017-08-141-1/+1
| | | | | | | | | | | | Test Plan: `GHCi.loadDll "/usr/lib/libc++.so` now works on FreeBSD. Reviewers: austin, bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3841
* Linker: Fix whitespaceBen Gamari2017-06-081-16/+16
| | | | [skip ci]
* Better import library support for WindowsTamar Christina2017-06-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The import library support added for 7.10.3 was only a partial one. This support was predicated on using file extensions to determine whether or not a library was an import library. It also couldn't handle libraries with multiple dll pointers. This is a rewrite of that patch and fully integrating it into the normal archive parsing and loading routines. This solves a host of issues, among others allowing us to finally use `-lgcc_s`. This also fixes a problem with our previous implementation, where we just loaded the DLL and moved on. Doing this had the potential of using the wrong symbol at resolve time. Say a DLL already loaded (A.dll) has symbol a exported (dependency of another dll perhaps). We find an import library `B.lib` explicitly defining an export of `a`. we load `B.dll` but this gets put after `A.dll`, at resolve time we would use the value from `A` instead of `B` which is what we wanted. Test Plan: ./valide and make test TEST=13606 Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force GHC Trac Issues: #13606, #12499, #12498 Differential Revision: https://phabricator.haskell.org/D3513
* Abandon typedefing the {Section,ObjectCode}FormatInfo structsGabor Greif2017-05-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow-up to @angerman 's refactoring for ELF that happened with e5e8646d3c6af82549b55fbee6764b087144a7ec My previous commit a6675a93efe7cae2f206508047a39e73ce4e92a5 corrected a typedef redefinition issue with GCC v4.4 (which is pervasive with RHEL 6). Now the problem has resurfaced. Instead of dancing after the different compiler's pipe, I decided to eliminate the typedefs altogether and refer to the struct namespace explicitly. Added a note to describe why typedefs are not applied on customisable structs. Reviewers: austin, bgamari, erikd, simonmar Subscribers: rwbarton, thomie, angerman Differential Revision: https://phabricator.haskell.org/D3527
* [linker] Add ocInit/ocDeinit for ELFMoritz Angermann2017-05-011-18/+38
| | | | | | | | | | | | | | | This fills out the extended `info` structs, and will be subsequently used in the arm and arm64 linker for elf. Depends on: D3446, D3459 Reviewers: bgamari, austin, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3447
* Prefer #if defined to #ifdefBen Gamari2017-04-281-10/+10
| | | | Our new CPP linter enforces this.
* catch the case where there is no symCmdMoritz Angermann2017-04-211-0/+2
| | | | | | | | | | | | | | | | | We do check for symCmd, to set the info->nlist value, but forgot to do the same check for info->names. Thus when trying to extract stroff from symCmd, we hit a segfault. Test Plan: The validation failure on windows is rather suspicious... let's try this one Reviewers: bgamari, adinapoli, austin, erikd, simonmar Reviewed By: adinapoli Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D3468
* Revert "linker/mach-o: Catch the case where there is no symCmd"Ben Gamari2017-04-181-2/+0
| | | | | | This causes validation failures on Windows. This reverts commit 6c05b27e5bafe9f232e7014f4760335f5e3ba591.
* linker/mach-o: Catch the case where there is no symCmdMoritz Angermann2017-04-151-0/+2
| | | | | | | | | | | | | | We do check for symCmd, to set the info->nlist value, but forgot to do the same check for info->names. Thus when trying to extract stroff from symCmd, we hit a segfault. Reviewers: bgamari, adinapoli, austin, erikd, simonmar Reviewed By: bgamari, adinapoli Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3459
* rts: Fix lingering #ifsBen Gamari2017-04-041-3/+3
| | | | These were missed in D3278.
* Add ocInit_MachOMoritz Angermann2017-03-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds ocInit_MachO function, used to populate the extended ObjectCode structure, and the corresponding stgFree. It also adds defines for iOS, such that MachO.o is also compiled for iOS targets. Depends on D3239 --- This is just one of the pieces for the rts linker support for ios (aarch64-macho) --- The following diagram and legend tries to explain the dependencies a bit: ``` .- D3240 v D3255 <- D3252 <- This <- D3239 ^ '- D3238 ``` - In D3238 we started allowing preloading object code with mmap in iOS, where we can't have r+w+x. - In D3239 we introduced a richer extension of the object code data type to make working with mach-o files easier. - In D3240 we set the stage to allow loading archives (.a) on iOS - In D3251 we added init and deinit functions to populate and depopulate the enriched object code data structure for mach-o files. - In D3252 we refactored most of the MachO.c file to use the new types and data structure. - in D3255 we finally introduce the aarch64-mach-o linker. Reviewers: rwbarton, bgamari, austin, erikd, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3251
* rts linker: Introduce MachOTypesMoritz Angermann2017-03-261-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff introduces MachOTypes, to reduce the need to typing `struct` all the time. It also coaleces the 64 and non 64 structs. It also adds additional fiedls to the object code structure for macho, which makes working with macho object code much simpler and requires less passing around of variabls or address recomputation for the header, symbol table, etc... Furthermore this diff introduces a type for a linked list of stubs. I had to move the #ifdef from the bottom of the file up, to be able to extend the object code structure conditional on the use of the macho file format. This is just one of the pieces for the rts linker support for ios (aarch64-macho) --- The following diagram and legend tries to explain the dependencies a bit: ``` .- D3240 v D3255 <- D3252 <- D3251 <- This ^ '- D3238 ``` - In D3238 we started allowing preloading object code with mmap in iOS, where we can't have r+w+x. - In D3239 we introduced a richer extension of the object code data type to make working with mach-o files easier. - In D3240 we set the stage to allow loading archives (.a) on iOS - In D3251 we added init and deinit functions to populate and depopulate the enriched object code data structure for mach-o files. - In D3252 we refactored most of the MachO.c file to use the new types and data structure. - in D3255 we finally introduce the aarch64-mach-o linker. Reviewers: austin, erikd, simonmar, rwbarton, bgamari Subscribers: rwbarton, thomie, ryantrinkle Differential Revision: https://phabricator.haskell.org/D3239
* Make mmap r+w only during preload for iOS.Moritz Angermann2017-03-261-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we do not yet enable mmap for ios builds. If we later do, we must not try to mmap r+w+x, on iOS as that clearly fails. This diff also adds a check for the successful mmaping. I don't think we can blanket change this to r+w for every case, unless we are absolutely sure that we are going to remap this and set +x where needed. This is just one of the pieces for the rts linker support for ios (aarch64-macho) --- The following diagram and legend tries to explain the dependencies a bit: ``` .- D3240 v D3255 <- D3252 <- D3251 <- D3239 ^ '- This ``` - In D3238 we started allowing preloading object code with mmap in iOS, where we can't have r+w+x. - In D3239 we introduced a richer extension of the object code data type to make working with mach-o files easier. - In D3240 we set the stage to allow loading archives (.a) on iOS - In D3251 we added init and deinit functions to populate and depopulate the enriched object code data structure for mach-o files. - In D3252 we refactored most of the MachO.c file to use the new types and data structure. - in D3255 we finally introduce the aarch64-mach-o linker. Reviewers: ezyang, austin, erikd, simonmar, bgamari, rwbarton Reviewed By: bgamari Subscribers: rwbarton, ryantrinkle, thomie Differential Revision: https://phabricator.haskell.org/D3238
* Make list of deprecated symbols on Windows weak.Tamar Christina2017-02-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a unfortunate workaround in place for the fact that most packages out there use POSIX names for symbols even on Windows. This means that we have to recognize e.g. both `_ungetch` and `ungetch`. The former is the actual symbol name on windows and the latter is the POSIX variant. The problem is that on normal windows programs `ungetch` should not be in the global namespace. To work around this, we now mark the deprecated symbols as weak symbols in the global namespace. This provides the flexibility we need: * If you use the symbol without defining it, we assume you meant to use the POSIX variant. * If you actually define the symbol, we'll hence forth use that definition and assume you didn't mean to use POSIX code. This is how MingW64's wrapper also works. This requires D3028. Fixes #13210. Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3154
* Slighly clean up symbol loading error.Tamar Christina2017-01-301-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The symbol not found error that is triggered during lazy-loading was a bit chaotic before. This reformats it a bit to: ``` ghc-stage2.exe: | E:\...\libLLVMSupport.a: unknown symbol `_ZN4llvm5APIntC1Ejyb' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm5APInt14AssignSlowCaseERKS0_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm13ConstantRangeC1ENS_5APIntES1_' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm14FoldingSetImplC2Ej' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZN4llvm15LLVMContextImplD1Ev' ghc-stage2.exe: | E:\...\libLLVMLTO.a: unknown symbol `_ZN4llvm11LLVMContextD1Ev' ghc-stage2.exe: | E:\...\libLLVMCore.a: unknown symbol `_ZNK4llvm5Value10getContextEv' ghc-stage2.exe: ^^ Could not load 'LLVMIsMultithreaded', dependency unresolved. See top entry above. ``` I have also thought about also showing the demangled names, as it may be useful for the end user. `libgcc` seems to provide a method for this so we wouldn't need any extra dependency. Any thoughts on this or would it not be useful? Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3027 GHC Trac Issues: #13093, #13113
* Testsuite: Skip failing tests on PowerPC 64-bitPeter Trommler2016-12-271-7/+13
| | | | | | | | | | | | | | | | | | | The Power ISA says the result of a division by zero is undefined. So ignore stdout on PowerPC 64-bit systems. Disable ext-interp tests on 64-bit PowerPC. We don't have support for PowerPC 64-bit ELF in the RTS linker, which is needed for the external interpreter. Test Plan: ./validate Reviewers: austin, simonmar, hvr, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2782
* Use C99's boolBen Gamari2016-11-291-5/+5
| | | | | | | | | | | | 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
* rts: Fix LoadArchive on OS XBen Gamari2016-11-111-6/+3
|
View Lorry Controller Status