summaryrefslogtreecommitdiff
path: root/rts/Linker.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove cygwin32_HOST_OS #ifdefsErik de Castro Lopo2015-10-261-17/+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/Linker.c: Convert #if/#else to if/elseErik de Castro Lopo2015-10-251-22/+28
| | | | | | | | | | Test Plan: validate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1366
* rts/Linker.c: Split RTS symbols out into separate fileErik de Castro Lopo2015-10-241-1183/+2
| | | | | | | | | | | | | 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
* Fix caching of pagesizeSimon Marlow2015-10-211-3/+2
| | | | | | | | | | | | Summary: Spotted by @erikd Test Plan: validate Reviewers: austin, bgamari, erikd Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1345
* fix RTS linker compilation failure on SolarisKarel Gardas2015-10-181-1/+2
| | | | | | | | Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1341
* Silence the linker on Windows so tests passTamar Christina2015-10-171-2/+2
| | | | | | | Silence the unconditional debugBelch statements recently added to HEAD which on Windows cause debug information to always be printed. Differential Revision: https://phabricator.haskell.org/D1338
* rts/Linker.c : Fix armhf build (#10977)Erik de Castro Lopo2015-10-161-6/+3
| | | | | | | | | | | | Test Plan: Validate on x86_64, PowerPC and Arm Reviewers: simonmar, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1330 GHC Trac Issues: #10977
* Fix windows build after D975Tamar Christina2015-10-161-0/+2
| | | | | | | | Add a missing #ifdef Reviewed By: simonmar Differential Revision: https://phabricator.haskell.org/D1328
* ELF/x86_64: map object file sections separately into the low 2GBSimon Marlow2015-10-151-248/+645
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix GHCi on Arm (#10375).Erik de Castro Lopo2015-10-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Arm has two instruction sets, Arm and Thumb, and an execution mode for each. Executing Arm code in Thumb mode or vice-versa will likely result in an Illegal instruction exception. Furthermore, Haskell code compiled via LLVM was generating Arm instructions while C code compiled via GCC was generating Thumb code by default. When these two object code types were being linked by the system linker, all was fine, because the system linker knows how to jump and call from one instruction set to the other. The first problem was with GHCi's object code loader which did not know about Thumb vs Arm. When loading an object file `StgCRun` would jump into the loaded object which could change the mode causing a crash after it returned. This was fixed by forcing all C code to generate Arm instructions by passing `-marm` to GCC. The second problem was the `mkJumpToAddr` function which was generating Thumb instructions. Changing that to generate Arm instructions instead results in a working GHCi on Arm. Test Plan: validate on x86_64 and arm Reviewers: bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1323 GHC Trac Issues: #10375
* Make Windows linker more robust to unknown sectionsTamar Christina2015-10-031-121/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows Linker has 3 main parts that this patch changes. 1) Identification and classification of sections 2) Adding of symbols to the symbols tables 3) Reallocation of sections 1. Previously section identification used to be done on a whitelisted basis. It was also exclusively being done based on the names of the sections. This meant that there was a bit of a cat and mouse game between `GCC` and `GHC`. Every time `GCC` added new sections there was a good chance `GHC` would break. Luckily this hasn't happened much in the past because the `GCC` versions `GHC` used were largely unchanged. The new code instead treats all new section as `CODE` or `DATA` sections, and changes the classifications based on the `Characteristics` flag in the PE header. By doing so we no longer have the fragility of changing section names. The one exception to this is the `.ctors` section, which has no differentiating flag in the PE header, but we know we need to treat it as initialization data. The check to see if the sections are aligned by `4` has been removed. The reason is that debug sections often time are `1 aligned` but do have relocation symbols. In order to support relocations of `.debug` sections this check needs to be gone. Crucially this assumption doesn't seem to be in the rest of the code. We only check if there are at least 4 bytes to realign further down the road. 2. The second loop is iterating of all the symbols in the file and trying to add them to the symbols table. Because the classification of the sections we did previously are (currently) not available in this phase we still have to exclude the sections by hand. If they don't we will load in symbols from sections we've explicitly ignored the in # 1. This whole part should rewritten to avoid this. But didn't want to do it in this commit. 3. Finally the sections are relocated. But for some reason the PE files contain a Linux relocation constant in them `0x0011` This constant as far as I can tell does not come from GHC (or I couldn't find where it's being set). I believe this is probably a bug in GAS. But because the constant is in the output we have to handle it. I am thus mapping it to the constant I think it should be `0x0003`. Finally, static linking *should* work, but won't. At least not if you want to statically link `libgcc` with exceptions support. Doing so would require you to link `libgcc` and `libstd++` but also `libmingwex`. The problem is that `libmingwex` also defines a lot of symbols that the RTS automatically injects into the symbol table. Presumably because they're symbols that it needs. like `coshf`. The these symbols are not in a section that is declared with weak symbols support. So if we ever want to get this working, we should either a) Ask mingw to declare the section as such, or b) treat all a imported symbols as being weak. Though this doesn't seem like it's a good idea.. Test Plan: Running ./validate for both x86 and x86_64 Also running the specific test case for #10672 make TESTS="T10672_x86 T10672_x64" Reviewed By: ezyang, thomie, austin Differential Revision: https://phabricator.haskell.org/D1244 GHC Trac Issues: #9907, #10672, #10563
* Upgrade GCC to 5.2.0 for Windows x86 and x86_64Tamar Christina2015-08-121-269/+307
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does a few things - Moved GHC x86 to MinGW-w64 (Using Awson's patch) - Moves Both GHCs to MSYS2 toolchains - Completely removes the dependencies on the git tarball repo - Downloads only the required tarball for the architecture for which we are building - Downloads the perl tarball is missing as well - Fixed a few bugs in the linker to fix tests on Windows The links currently point to repo.msys2.org and GitHub, it might be more desirable to mirror them on http://downloads.haskell.org/~ghc/mingw/ as with the previous patch attempt. For more details on what the MSYS2 packages I include see #10726 (Awson's comment). but it should contain all we need and no python or fortran, which makes the uncompressed tar a 1-2 hundreds mb smaller. The `GCC 5.2.0` in the package supports `libgcc` as a shared library, this is a problem since when compiling with -shared the produced dll now has a dependency on `libgcc_s_sjlj-1.dll`. To solve this the flag `-static-libgcc` is now being used for all GCC calls on windows. Test Plan: ./validate was ran both on x86 and x86_64 windows and compared against the baseline. A few test were failing due to Ld no longer being noisy. These were updated. The changes to the configure script *should* be validated by the build bots for the other platforms before landing Reviewers: simonmar, awson, bgamari, austin, thomie Reviewed By: thomie Subscribers: #ghc_windows_task_force, thomie, awson Differential Revision: https://phabricator.haskell.org/D1123 GHC Trac Issues: #10726, #9014, #9218, #10435
* disable check for .init_array section on OpenBSDKarel Gardas2015-07-011-2/+2
| | | | | | | | | | | | Summary: The patch disables check for .init_array section on OpenBSD. It is provided in OpenBSD ports tree and was done by Matthias Kilian. Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1023
* powerpc: add basic support for PLT relocations (#10402)Sergei Trofimovich2015-06-231-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a93ab43ab5f40cadbedea2f6342b93c245e91434 enabled support for proper PIC relocations from assembler. Commit adds support for relocations of type: R_PPC_REL16_HI R_PPC_REL16_HA R_PPC_REL16_LO R_PPC_PLTREL24 They are used only when GHC is built in DYNAMIC_GHC_PROGRAMS = NO mode. Verified by running the following test: // cat a.c #include <stdio.h> void ffi_a_hello (int i) { fprintf (stderr, "WEEEEEEEE: i=%d\n", i); } -- cat A.hs {-# LANGUAGE ForeignFunctionInterface #-} module A where import Foreign.C foreign import ccall "ffi_a_hello" a :: CInt -> IO () # ghc -fPIC -c a.c -fforce-recomp # ghc -fPIC -c A.hs -fforce-recomp # ghc --interactive ./a.o A ... *A> a 42 WEEEEEEEE: i=42 See gory details in Trac #10402. Signed-off-by: Colin Watson <cjwatson@debian.org> Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewed By: bgamari, austin Differential Revision: https://phabricator.haskell.org/D996 GHC Trac Issues: #10402
* Squash typos in commentsGabor Greif2015-06-121-1/+1
|
* Fix for CAF retention when dynamically loading & unloading codeSimon Marlow2015-06-081-3/+3
| | | | | | | | | | | | | In a situaion where we have some statically-linked code and we want to load and unload a series of objects, we need the CAFs in the statically-linked code to be retained indefinitely, while the CAFs in the dynamically-linked code should be GC'd as normal, so that we can detect when the code is unloadable. This was wrong before - we GC'd CAFs in the static code, leading to a crash in the rare case where we use a CAF, GC it, and then load a new object that uses it again. I also did some tidy up: RtsConfig now has a field keep_cafs to indicate whether we want CAFs to be retained in static code.
* rts/Linker.c: distinct between DATA and CODE labels when importingSergei Trofimovich2015-04-071-18/+42
| | | | | | | | | | | | | | | | | | | | The patch is a last major piece to make unregisterised GHC build under GCC's link-time optimizer. Before the patch we imported everything external as functions. Now we distinct between global variables and functions. The difference is crucial on ia64 and a complement to fixes: > d82f592522eb8e063276a8a8c87ab93e18353c6b > CMM: add a mechanism to import C .data labels > e18525fae273f4c1ad8d6cbe1dea4fc074cac721 > pprC: declare extern cmm primitives as functions, not data Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D797
* Replace hooks by callbacks in RtsConfig (#8785)Simon Marlow2015-04-071-5/+0
| | | | | | | | | | | | Summary: Hooks rely on static linking semantics, and are broken by -Bsymbolic which we need when using dynamic linking. Test Plan: Built it Reviewers: austin, hvr, tibbe Differential Revision: https://phabricator.haskell.org/D8
* rts/linker: make an error msg a debug msgAustin Seipp2015-04-031-2/+3
| | | | | | This fixes more testsuite failures on Windows. Signed-off-by: Austin Seipp <austin@well-typed.com>
* rts/linker: ignore unknown PE sectionsTamar Christina2015-02-231-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently the linker tries to see if it understands/knows every section in the PE file before it continues. If it encounters a section it doesn't know about it errors out. Every time there's a change in MinGW compiler that adds a new section to the PE file this will break the ghc linker. The new sections don't need to be understood by `ghc` to continue so instead of erroring out the section is just ignored. When running with `-debug` the sections that are ignored will be printed. Test Plan: See the file `ghcilinkerbug.zip` in #9907. 1) unzip file content. 2) open examplecpp.cabal and change base <4.8 to <4.9. 3) execute cabal file with cabal repl. Applying the patch makes `cabal repl` in step 3) work. Note that the file will fail on a `___mingw_vprintf` not being found. This is because of the `cc-options` specifying `-std=c++0x`, which will also require `libmingwex.a` to be linked in but wasn't specified in the cabal file. To fix this, remove the `cc-options` which defaults to c99. Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D671 GHC Trac Issues: #9907, #7103, #10051, #7056, #8546
* Allow the linker to run concurrently with the GCSimon Marlow2015-01-131-0/+13
|
* Trac #9878: Have StaticPointers support dynamic loading.Alexander Vershilov2015-01-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: A mutex is used to protect the SPT. unsafeLookupStaticPtr and staticPtrKeys in GHC.StaticPtr are made monadic. SPT entries are removed in a destructor function of modules. Authored-by: Facundo Domínguez <facundo.dominguez@tweag.io> Authored-by: Alexander Vershilov <alexander.vershilov@tweag.io> Test Plan: ./validate Reviewers: austin, simonpj, hvr Subscribers: carter, thomie, qnikst, mboes Differential Revision: https://phabricator.haskell.org/D587 GHC Trac Issues: #9878
* Implement -XStaticValuesFacundo Domínguez2014-12-091-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As proposed in [1], this extension introduces a new syntactic form `static e`, where `e :: a` can be any closed expression. The static form produces a value of type `StaticPtr a`, which works as a reference that programs can "dereference" to get the value of `e` back. References are like `Ptr`s, except that they are stable across invocations of a program. The relevant wiki pages are [2, 3], which describe the motivation/ideas and implementation plan respectively. [1] Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones. Towards Haskell in the cloud. SIGPLAN Not., 46(12):118–129, September 2011. ISSN 0362-1340. [2] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers [3] https://ghc.haskell.org/trac/ghc/wiki/StaticPointers/ImplementationPlan Authored-by: Facundo Domínguez <facundo.dominguez@tweag.io> Authored-by: Mathieu Boespflug <m@tweag.io> Authored-by: Alexander Vershilov <alexander.vershilov@tweag.io> Test Plan: `./validate` Reviewers: hvr, simonmar, simonpj, austin Reviewed By: simonpj, austin Subscribers: qnikst, bgamari, mboes, carter, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D550 GHC Trac Issues: #7015
* Revert "Revert "Add purgeObj() to remove the symbol table entries for an ↵Simon Marlow2014-12-051-23/+51
| | | | | | object"" This reverts commit 7932b2adaecac6c86038176d909c20ad1b1f9604.
* Revert "Revert "Make the linker API thread-safe""Simon Marlow2014-12-051-37/+72
| | | | | | | 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-69/+36
| | | | | | | | | | | | | | | | 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.
* Revert "Add purgeObj() to remove the symbol table entries for an object"Simon Peyton Jones2014-12-021-51/+23
| | | | | | | | | | | | | | | | 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.
* Fix obscure problem with using the system linker (#8935)Peter Trommler2014-11-301-9/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In a statically linked GHCi symbol `environ` resolves to NULL when called from a Haskell script. When resolving symbols in a Haskell script we need to search the executable program and its dependent (DT_NEEDED) shared libraries first and then search the loaded libraries. We want to be able to override functions in loaded libraries later. Libraries must be opened with local scope (RTLD_LOCAL) and not global. The latter adds all symbols to the executable program's symbols where they are then searched in loading order. We want reverse loading order. When libraries are loaded with local scope the dynamic linker cannot use symbols in that library when resolving the dependencies in another shared library. This changes the way files compiled to object code must be linked into temporary shared libraries. We link with the last temporary shared library created so far if it exists. Since each temporary shared library is linked to the previous temporary shared library the dynamic linker finds the latest definition of a symbol by following the dependency chain. See also Note [RTLD_LOCAL] for a summary of the problem and solution. Cherry-picked commit 2f8b4c Changed linker argument ordering On some ELF systems GNU ld (and others?) default to --as-needed and the order of libraries in the link matters. The last temporary shared library, must appear before all other libraries. Switching the position of extra_ld_inputs and lib_path_objs does that. Fixes #8935 and #9186 Reviewers: austin, hvr, rwbarton, simonmar Reviewed By: simonmar Subscribers: thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D349 GHC Trac Issues: #8935, #9186, #9480
* Add purgeObj() to remove the symbol table entries for an objectSimon Marlow2014-11-281-23/+51
| | | | | | | | 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 API thread-safeSimon Marlow2014-11-281-36/+69
| | | | | | 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.
* Per-thread allocation counters and limitsSimon Marlow2014-11-121-0/+4
| | | | | | | | This reverts commit f0fcc41d755876a1b02d1c7c79f57515059f6417. New changes: now works on 32-bit platforms too. I added some basic support for 64-bit subtraction and comparison operations to the x86 NCG.
* Use snwprintf instead of swprintf in rts/Linker.c.Gintautas Miliauskas2014-10-291-4/+5
| | | | | | | | | | | | | | | | | | | | Summary: swprintf has different signatures in mingw32, where it does not include the buffer size, and in mingw-w64, where it does. That of course breaks the code as mingw-w64 treats the pointer to the format string as a size_t. snwprintf is available in both environments and is consistent, so use that instead. Reviewers: simonmar, austin Reviewed By: austin Subscribers: #ghc_windows_task_force, thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D372 GHC Trac Issues: #9726
* Fixed unused variable warning on mingw32/i686 in rts/Linker.cGintautas Miliauskas2014-10-291-2/+2
| | | | | | | | | | | | The warning was breaking validate.sh runs due to -Wall. Reviewers: austin Reviewed By: austin Subscribers: #ghc_windows_task_force, thomie, carter, simonmar Differential Revision: https://phabricator.haskell.org/D400
* Fix windows build failure.Austin Seipp2014-10-241-6/+8
| | | | | | Authored-by: Simon Marlow <marlowsd@gmail.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Revert "Rename _closure to _static_closure, apply naming consistently."Edward Z. Yang2014-10-201-2/+2
| | | | | | | This reverts commit 35672072b4091d6f0031417bc160c568f22d0469. Conflicts: compiler/main/DriverPipeline.hs
* Revert "Check for staticclosures section in Windows linker."Edward Z. Yang2014-10-201-1/+0
| | | | This reverts commit 2fc0c6cf594731f343b4f8a5b3ecf9e72db4c3c0.
* Revert "Fix typo in section name: no leading period."Edward Z. Yang2014-10-201-1/+1
| | | | This reverts commit e8dac6dc60beea863c3a5daded68f5157ab546fb.
* Fix build on some platformsSimon Marlow2014-10-121-0/+2
|
* Make the linker more robust to errorsSimon Marlow2014-10-081-135/+245
| | | | | | | | | | | | | | | | | | | | 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
* Fix typo in section name: no leading period.Edward Z. Yang2014-10-031-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Check for staticclosures section in Windows linker.Edward Z. Yang2014-10-031-0/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Rename _closure to _static_closure, apply naming consistently.Edward Z. Yang2014-10-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In preparation for indirecting all references to closures, we rename _closure to _static_closure to ensure any old code will get an undefined symbol error. In order to reference a closure foobar_closure (which is now undefined), you should instead use STATIC_CLOSURE(foobar). For convenience, a number of these old identifiers are macro'd. Across C-- and C (Windows and otherwise), there were differing conventions on whether or not foobar_closure or &foobar_closure was the address of the closure. Now, all foobar_closure references are addresses, and no & is necessary. CHARLIKE/INTLIKE were not changed, simply alpha-renamed. Part of remove HEAP_ALLOCED patch set (#8199) Depends on D265 Signed-off-by: Edward Z. Yang <ezyang@mit.edu> Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D267 GHC Trac Issues: #8199
* Revert "rts: add Emacs 'Local Variables' to every .c file"Simon Marlow2014-09-291-8/+0
| | | | This reverts commit 39b5c1cbd8950755de400933cecca7b8deb4ffcd.
* `M-x delete-trailing-whitespace` & `M-x untabify`Herbert Valerio Riedel2014-09-241-1/+1
|
* Implement `decodeDouble_Int64#` primopHerbert Valerio Riedel2014-09-171-0/+1
| | | | | | | | | | | | | | | The existing `decodeDouble_2Int#` primop is rather inconvenient to use (and in fact is not even used by `integer-gmp`) as the mantissa is split into 3 components which would actually fit in an `Int64#` value. However, `decodeDouble_Int64#` is to be used by the new `integer-gmp2` re-implementation (see #9281). Moreover, `decodeDouble_2Int#` performs direct bit-wise operations on the IEEE representation which can be replaced by a combination of the portable standard C99 `scalbn(3)` and `frexp(3)` functions. Differential Revision: https://phabricator.haskell.org/D160
* Revert "Revert "rts/base: Fix #9423"" and resolve issue that caused the revert.Andreas Voellmy2014-09-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This reverts commit 4748f5936fe72d96edfa17b153dbfd84f2c4c053. The fix for #9423 was reverted because this commit introduced a C function setIOManagerControlFd() (defined in Schedule.c) defined for all OS types, while the prototype (in includes/rts/IOManager.h) was only included when mingw32_HOST_OS is not defined. This broke Windows builds. This commit reverts the original commit and resolves the problem by only defining setIOManagerControlFd() when mingw32_HOST_OS is defined. Hence the missing prototype error should not occur on Windows. In addition, since the io_manager_control_wr_fd field of the Capability struct is only usd by the setIOManagerControlFd, this commit includes the io_manager_control_wr_fd field in the Capability struct only when mingw32_HOST_OS is not defined. Test Plan: Try to compile successfully on all platforms. Reviewers: austin Reviewed By: austin Subscribers: simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D174
* rts/Linker.c: declare 'deRefStablePtr' as an exported 'rts' symbolSergei Trofimovich2014-08-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | $ inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -optc-fno-builtin -fno-ghci-history \ testsuite/tests/ffi/should_run/T4038.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS *Main> main <interactive>: /tmp/ghc16668_0/ghc16668_5.o: unknown symbol `deRefStablePtr' The reference to 'deRefStablePtr' is generated by 'compiler/deSugar/DsForeign.lhs': the_cfun = case maybe_target of Nothing -> text "(StgClosure*)deRefStablePtr(the_stableptr)" Just hs_fn -> char '&' <> ppr hs_fn <> text "_closure" Patch fixes all broken tests using 'import wrapper': TEST="ffi013 ffi010 ffi011 ffi005 ffi020 ffi006 ffi019 fed001 T1679 T4038" Tests manifested as broken only in DYNAMIC_GHC_PROGRAMS=NO builds, where GHCi's custom linker is used instead of system's linker. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* Revert "rts/base: Fix #9423"Austin Seipp2014-08-221-1/+0
| | | | | | | | | This should fix the Windows fallout, and hopefully this will be fixed once that's sorted out. This reverts commit f9f89b7884ccc8ee5047cf4fffdf2b36df6832df. Signed-off-by: Austin Seipp <austin@well-typed.com>
* Add a missing newline to a GHCi linker debugBelchReid Barton2014-08-201-1/+1
|
* rts/base: Fix #9423Andreas Voellmy2014-08-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix #9423. The problem in #9423 is caused when code invoked by `hs_exit()` waits on all foreign calls to return, but some IO managers are in `safe` foreign calls and do not return. The previous design signaled to the timer manager (via its control pipe) that it should "die" and when the timer manager returned to Haskell-land, the Haskell code in timer manager then signalled to the IO manager threads that they should return from foreign calls and `die`. Unfortunately, in the shutdown sequence the timer manager is unable to return to Haskell-land fast enough and so the code that signals to the IO manager threads (via their control pipes) is never executed and the IO manager threads remain out in the foreign calls. This patch solves this problem by having the RTS signal to all the IO manager threads (via their control pipes; and in addition to signalling to the timer manager thread) that they should shutdown (in `ioManagerDie()` in `rts/Signals.c`. To do this, we arrange for each IO manager thread to register its control pipe with the RTS (in `GHC.Thread.startIOManagerThread`). In addition, `GHC.Thread.startTimerManagerThread` registers its control pipe. These are registered via C functions `setTimerManagerControlFd` (in `rts/Signals.c`) and `setIOManagerControlFd` (in `rts/Capability.c`). The IO manager control pipe file descriptors are stored in a new field of the `Capability_ struct`. Test Plan: See the notes on #9423 to recreate the problem and to verify that it no longer occurs with the fix. Auditors: simonmar Reviewers: simonmar, edsko, ezyang, austin Reviewed By: austin Subscribers: phaskell, simonmar, ezyang, carter, relrod Differential Revision: https://phabricator.haskell.org/D129 GHC Trac Issues: #9423, #9284
View Lorry Controller Status