summaryrefslogtreecommitdiff
path: root/compiler/ghci/Linker.hs
Commit message (Collapse)AuthorAgeFilesLines
* Maintain separate flags for C++ compiler invocationswip/T16738Ben Gamari2019-06-121-1/+1
| | | | | | | Previously we would pass flags intended for the C compiler to the C++ compiler (see #16738). This would cause, for instance, `-std=gnu99` to be passed to the C++ compiler, causing spurious test failures. Fix this by maintaining a separate set of flags for C++ compilation invocations.
* Fix space leaks in dynLoadObjs (#16708)Ryan Scott2019-05-311-7/+7
| | | | | | | | | | | When running the test suite on a GHC built with the `quick` build flavour, `-fghci-leak-check` noticed some space leaks. Careful investigation led to `Linker.dynLoadObjs` being the culprit. Pattern-matching on `PeristentLinkerState` and a dash of `$!` were sufficient to fix the issue. (ht to mpickering for his suggestions, which were crucial to discovering a fix) Fixes #16708.
* Inline `Settings` into `DynFlags`John Ericson2019-05-291-1/+1
| | | | | | | | | | After the previous commit, `Settings` is just a thin wrapper around other groups of settings. While `Settings` is used by GHC-the-executable to initalize `DynFlags`, in principle another consumer of GHC-the-library could initialize `DynFlags` a different way. It therefore doesn't make sense for `DynFlags` itself (library code) to separate the settings that typically come from `Settings` from the settings that typically don't.
* Allow for multiple linker instances. Fixes Haskell portion of #3372.Julian Leviston2019-05-211-93/+64
|
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-1/+1
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Check that libs found by GCC aren't foldersAlec Theriault2019-01-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We use 'gcc -B<base-location> --print-file-name mylib.a' as a way of checking if 'gcc' can discover 'mylib.a' at the given location. However, this can break down if there is a folder caller 'mylib.a' that 'gcc' can discover. We can guard against this by explicitly checking that the path returned by 'gcc' is a file. This may seem like a far-fetched scenario, but since 3d17f1f10fc00540ac052f2fd03182906aa47e35, we look for libraries without any prefix or suffix (ie. 'extra-libraries: softfloat', we look for just 'softfloat' as well as 'softloat.a', 'softfloat.dll.a', etc.) which means that there might actusally be a folder of that name in one of the base locations. Reviewers: Phyx, bgamari, hvr, angerman Reviewed By: Phyx, angerman Subscribers: angerman, rwbarton, carter GHC Trac Issues: #16063 Differential Revision: https://phabricator.haskell.org/D5462
* Merge sections in profiling .a to .p_o and use it whenever it existsZejun Wu2018-12-171-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We do this for vanilla way already. Let's also merge sections for profiling way and use it instead of the .a library when it exists. Test Plan: ``` $ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter GHCi, version 8.7.20180921: http://www.haskell.org/ghc/ :? for help Prelude> pid <- System.Posix.Process.getProcessID Prelude> maps <- readFile $ "/proc/" ++ show pid ++ "/maps" Prelude> pid 3807346 Prelude> putStrLn $ unlines $ take 20 $ lines maps 00400000-02103000 r-xp 00000000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02104000-02106000 r--p 01d03000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02106000-02417000 rw-p 01d05000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02417000-0280a000 rw-p 00000000 00:00 0 [heap] 40098000-400b0000 rwxp 000d2000 00:1a 199276023 /data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o 400b7000-400d8000 rwxp 00000000 00:00 0 401d1000-401d2000 rwxp 000e9000 00:1a 199276023 /data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o 40415000-40419000 rwxp 0000b000 00:1a 199275165 /data/users/watashi/ghc/libraries/deepseq/dist-install/build/HSdeepseq-1.4.4.0.p_o 404f8000-40526000 rwxp 000af000 00:1a 199274234 /data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o ``` Reviewers: simonmar, bgamari, austin, hvr Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5169
* RTS linker: don't crash early when not finding extra-librariesKyrill Briantsev2018-12-111-9/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow GHCi to not crash when no assumed DLL is found in the standard location. E.g. when loading the package built "dyn" way, we may well have the package's DLL around, and it's the system linker which loads necessary dependencies. Why does this (partially) fix #11042? It's because we often (and when having packages built `dyn` way -- almost always) don't need to load anything recorded in the `extra-libraries` stanza, since if the package DLL exists, GHCi linker simply calls the system linker (via `dlopen`/ `LoadLibrary` APIs) to load it and doesn't bother to load package prelinked object file (if any) or package static library. Thus, all "regular" (with no fancy low-level package content manipulation) packages built "dyn" way should be OK after this fix. Reviewers: hvr, bgamari, int-index Reviewed By: bgamari, int-index Subscribers: Phyx, int-index, rwbarton, carter GHC Trac Issues: #11042 Differential Revision: https://phabricator.haskell.org/D5170
* Stop the linker panicMoritz Angermann2018-08-061-25/+34
| | | | | | | | | | | | | | | | | | | | | | | If we fail to initialize the liker properly, we still set the `initLinkerDone`. In fact we even set that prior to actually initializing the linker. However if the linker initialization fails, we the `Done` state is still true. As such we run into the `Dynamic Linker not initialised` error. Which while technically corret is confusing as it pulls the attation away from the real issue. This change puts the Done state into an MVar, and as such ensureing that all parallel access needs to wait for the linker to be actually initialized, or try to re-initilize if it fails. Reviewers: bgamari, RyanGlScott, simonmar, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #9868, #10355, #13137, #13607, #13531 Differential Revision: https://phabricator.haskell.org/D5012
* linker: Nub rpathsMoritz Angermann2018-08-011-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling and linking files in `ghci`, we keep adding rpath arguments to the linker command invoation. If those are identical we should `nub` them out. Otherwise we not only risk overflowing the argument limit, but also embed huge amounts of identical rpath values into the dynamic library, eventually leading to the overflow of the load command size limit, due to the number of rpath entries alone. A further improvement could be to pass `-Xlinker -dead_strip_dylibs`; that however might be stipping too aggressively, and potentially lead to missing symbols? For the time being I suggest to only do the nubbing and if need be to provide -Wl,-dead_strip_dylibs when invoking ghci. Test Plan: ./validate Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15446 Differential Revision: https://phabricator.haskell.org/D5021
* Fix space leaksSimon Marlow2018-07-161-14/+19
| | | | | | | | | | | | | | | | | | | | | Summary: All these were detected by -fghci-leak-check when GHC was compiled *without* optimisation (e.g. using the "quick" build flavour). Unfortunately I don't know of a good way to keep this working. I'd like to just disable the -fghci-leak-check flag when the compiler is built without optimisation, but it doesn't look like we have an easy way to do that. And even if we could, it would be fragile anyway, Test Plan: `cd testsuite/tests/ghci; make` Reviewers: bgamari, hvr, erikd, tdammers Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #15246 Differential Revision: https://phabricator.haskell.org/D4872
* Fix #9438 by converting a panic to an error messageRyan Scott2018-04-131-2/+13
| | | | | | | | | | | | | | | | | | Previously, GHC was quite eager to panic whenever it was fed an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an explicit error message instead, so this patch accomplishes just that. Test Plan: make test TEST=T14708 Reviewers: Phyx, hvr, bgamari Reviewed By: Phyx Subscribers: thomie, carter GHC Trac Issues: #9438, #14708, #15032 Differential Revision: https://phabricator.haskell.org/D4589
* Linker: ignore empty paths in addEnvPathsÖmer Sinan Ağacan2018-01-261-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously `splitEnv` worked like this: > splitEnv "foo:::bar::baz:" ["foo","","","bar","","baz",""] with this patch: > splitEnv working_dir "foo:::bar:baz:" ["foo",working_dir,working_dir"bar","baz",working_dir] This fixes #14695, where having a trailing `:` in the env variable caused ghci to pass empty `-B` parameter to `gcc`, which in turned caused the next parameter (`--print-file-name`) to be considered as the argument to `-B`. As a result ghci did not work. The `working_dir` argument is to have a similar behavior with POSIX: according to chapter 8.3 zero-length prefix means current working directory. Reviewers: hvr, bgamari, AndreasK, simonmar Reviewed By: bgamari, AndreasK, simonmar Subscribers: AndreasK, rwbarton, thomie, carter GHC Trac Issues: #14695 Differential Revision: https://phabricator.haskell.org/D4330
* Support LIBRARY_PATH and LD_LIBRARY_PATH in rtsBen Gamari2018-01-151-6/+31
| | | | | | | | | | | | | | | | | | | | | | | | | `LIBRARY_PATH` is used to find libraries and other link artifacts while `LD_LIBRARY_PATH` is used to find shared libraries by the loader. Due to an implementation detail on Windows, using `LIBRARY_PATH` will automatically add the path of any library found to the loader's path. So in that case `LD_LIBRARY_PATH` won't be needed. Test Plan: ./validate along with T14611 which has been made Windows only due to linux using the system linker/loader by default. So I feel a testcase there is unwarranted as the support is indirect via glibc. Reviewers: hvr, bgamari, erikd, simonmar, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, thomie, carter GHC Trac Issues: #14611 Differential Revision: https://phabricator.haskell.org/D4275
* Tweak link order slightly to prefer user shared libs before system ones.Tamar Christina2018-01-151-12/+36
| | | | | | | | | | | | | | | | | | | | | | | | | We currently always prefer shared libraries before import libraries and static libraries. This is because they're faster to load. The problem is when shared library are installed in the Windows directory. These would supersede any user specified ones. This is bad because e.g. Windows now ships icuuc, but an old version. If you try to use -licuuc then it would pick the Windows one instead of your user specified one. This patch slighly tweaks the ordering so user paths get prefered. Test Plan: ./validate Reviewers: RyanGlScott, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14456 Differential Revision: https://phabricator.haskell.org/D4274
* Optimize linker by minimizing calls to tryGCC to avoid fork/exec overhead.Tamar Christina2017-10-031-20/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows process creations are fairly expensive. As such calling them in what's essentially a hot loop is also fairly expensive. Each time we make a call to `tryGCC` the following fork/exec/wait happen ``` gcc -> realgcc -> cc1 ``` This is very problematic, because according to the profiler about 20% of the time is spent on just process creation and spin time. The goal of the patch is to mitigate this by asking GCC once for it's search directories, caching these (because it's very hard to change these at all after the process started since GCC's base dirs don't change unless with extra supplied `-B` flags.). We also do the same for the `findSysDll` function, since this computes the search path every time by registery accesses etc. These changes and D3909 drop GHC on Windows startup time from 2-3s to 0.5s. The remaining issue is a 1.5s wait lock on `CONIN$` which can be addressed with the new I/O manager code. But this makes GHCi as responsive on Windows as GHC 7.8 was. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3910
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | This switches the compiler/ component to get compiled with -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all modules. This is motivated by the upcoming "Prelude" re-export of `Semigroup((<>))` which would cause lots of name clashes in every modulewhich imports also `Outputable` Reviewers: austin, goldfire, bgamari, alanz, simonmar Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari Differential Revision: https://phabricator.haskell.org/D3989
* Drop GHC 7.10 compatibilityRyan Scott2017-08-011-9/+0
| | | | | | | | | | | | | | | | GHC 8.2.1 is out, so now GHC's support window only extends back to GHC 8.0. This means we can delete gobs of code that was only used for GHC 7.10 support. Hooray! Test Plan: ./validate Reviewers: hvr, bgamari, austin, goldfire, simonmar Reviewed By: bgamari Subscribers: Phyx, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3781
* Avoid linear lookup in unload_wkr in the LinkerBartosz Nitka2017-07-221-2/+2
| | | | | | | | | | | | | | | | | | | | I've encountered an issue with following reproduction steps: * `:load` a large number of modules (~2000) * compile a BCO that depends on many other BCOs from many other modules * `:reload` * try to compile anything, even `1` works Before this patch the last step takes ~5s. It takes 80ms after. Test Plan: harbormaster Reviewers: simonmar, austin, hvr, bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3770
* Refactor temp files cleanupDouglas Wilson2017-06-081-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove filesToNotIntermediateClean from DynFlags, create a data type FilesToClean, and change filesToClean in DynFlags to be a FilesToClean. Modify SysTools.newTempName and the Temporary constructor of PipelineMonad.PipelineOutput to take a TempFileLifetime, which specifies whether a temp file should live until the end of GhcMonad.withSession, or until the next time cleanIntermediateTempFiles is called. These changes allow the cleaning of intermediate files in GhcMake to be much more efficient. HscTypes.hptObjs is removed as it is no longer used. A new performance test T13701 is added, which passes both with and without -keep-tmp-files. The test fails by 25% without the patch, and passes when -keep-tmp-files is added. Note that there are still at two hotspots caused by algorithms quadratic in the number of modules, however neither of them allocate. They are: * DriverPipeline.compileOne'.needsLinker * GhcMake.getModLoop DriverPipeline.compileOne'.needsLinker is changed slightly to improve the situation. I don't like adding these Types to DynFlags, but they need to be seen by Dynflags, SysTools and PipelineMonad. The alternative seems to be to create a new module. Reviewers: austin, hvr, bgamari, dfeuer, niteria, simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13701 Differential Revision: https://phabricator.haskell.org/D3620
* askCc should be using the linker, not the compilerSimon Marlow2017-03-311-1/+1
| | | | | | | | | | | | | | | | | When GHCi tries to find a shared lib, it calls "gcc --print-file-name" to ask gcc where to find it. But since we're looking for libraries, we're really using the linker here, not the C compiler, so we should be respecting the values of -pgml and -optl rather than -pgmc and -optc. Test Plan: validate Reviewers: bgamari, niteria, austin, hvr, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3393
* ghci/Linker.hs: Fix a typo in error messageÖmer Sinan Ağacan2017-03-241-1/+1
|
* Introduce putLogMsgBen Gamari2017-03-151-9/+8
| | | | | | | | | | | | | This factors out the repetition of (log_action dflags dflags) and will hopefully allow us to someday better abstract log output. Test Plan: Validate Reviewers: austin, hvr, goldfire Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3334
* Add GCC bin folder to search path.Tamar Christina2017-03-061-2/+4
| | | | | | | | | | | | | | | | | | D3155 added pthread by default to GHCi. However this was only tested using something running in an msys2 shell. As it turns out it's been picking up pthread in the environment and not the inplace gcc. This results in an error when using ghci outside of msys2. Test Plan: start cmd, start ghc-stage2 --interactive Reviewers: austin, hvr, bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3279
* Extend Windows runtime loader libsearchTamar Christina2017-03-021-4/+7
| | | | | | | | | | | | | | | | | | | | | | This adds `.obj` extension to the list of valid object file (we really shouldn't be using extensions but instead trying to read the file and see if the header makes sense.). Microsoft compilers use .obj instead of .o for object files. This also adds support to finding static archives when the "lib" prefix is already in the filename. e.g. `-llibfoo` to find `libfoo.a`. This is inline with binutils. Test Plan: ./validate Reviewers: simonmar, erikd, bgamari, hvr, austin Reviewed By: bgamari Subscribers: RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3082
* Load `pthreads` by default on WindowsTamar Christina2017-02-261-1/+13
| | | | | | | | | | | | | | | | | | | | | The GCC Bindists that we use compile with `pthread` enabled by default. This means that on every link the dll is passed as a dependency by the driver. Lots of packages depend on it but the runtime linker doesn't provide it by default making compiled code work but not interpreted. Following D3028 `pthreads` would be provided by default ONLY when linked dynamicly, which we don't support yet (See D2592). Until this is the case we need to manually provide `libpthreads`. Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3155
* Ditch static flagsSylvain Henry2017-02-021-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch converts the 4 lasting static flags (read from the command line and unsafely stored in immutable global variables) into dynamic flags. Most use cases have been converted into reading them from a DynFlags. In cases for which we don't have easy access to a DynFlags, we read from 'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'. It's not perfect (not thread-safe) but it is still better as we can set/unset these 4 flags before each run when using GHC API. Updates haddock submodule. Rebased and finished by: bgamari Test Plan: validate Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2839 GHC Trac Issues: #8440
* Always use -Xlinker for -rpathBartosz Nitka2017-01-211-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | Currently we use `-Wl` which takes a list of comma-separated options. Unfortunately that breaks when you use it with `-rpath` and a path that has commas in them. Buck, the build system, produces paths with commas in them. `-Xlinker` doesn't have this disadvantage and as far as I can tell is supported by both `gcc` and `clang`. Anecdotally `nvcc` supports `-Xlinker`, but not `-Wl`. Test Plan: ./validate, harbourmaster Reviewers: nomeata, simonmar, austin, bgamari, hvr Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2971
* Fix abort and import lib search on WindowsTamar Christina2017-01-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: Apparently `sysErrorBelch` doesn't terminate the program anymore making previously unreachable code now execute. If a dll is not found the error message we return needs to be a heap value. Secondly also allow the pattern `lib<name>` to be allowed for finding an import library with the name `lib<name>.dll.a`. Test Plan: ./validate, new tests T13082_good and T13082_fail Reviewers: austin, RyanGlScott, hvr, erikd, simonmar, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2941 GHC Trac Issues: #13082
* Simplify CPP logic as we now need v7.10 for bootstrappingGabor Greif2017-01-131-5/+1
|
* Allow use of the external interpreter in stage1.Shea Levy2016-12-201-0/+10
| | | | | | | | | | | | | | | | | | | Summary: Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. This was originally added in https://phabricator.haskell.org/D2826 but that led to a compatibility issue with ghc 7.10.x on Windows. That's fixed here and the revert reverted. Reviewers: goldfire, hvr, austin, bgamari, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2884 GHC Trac Issues: #13008
* Revert "Allow use of the external interpreter in stage1."Tamar Christina2016-12-191-10/+0
| | | | This reverts commit 52ba9470a7e85d025dc84a6789aa809cdd68b566.
* Allow use of the external interpreter in stage1.Shea Levy2016-12-171-0/+10
| | | | | | | | | | | | Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. Reviewers: simonmar, goldfire, austin, hvr, bgamari Reviewed By: simonmar Subscribers: RyanGlScott, mpickering, angerman, thomie Differential Revision: https://phabricator.haskell.org/D2826
* Make globals use sharedCAFMoritz Angermann2016-12-111-22/+22
| | | | | | | | | | | | | | | | | | | Summary: The use of globals is quite painful when multiple rts are loaded, e.g. when plugins are loaded, which bring in a second rts. The sharedCAF appraoch was employed for the FastStringTable; I've taken the libery to extend this to the other globals I could find. This is a reboot of D2575, that should hopefully not exhibit the same windows build issues. Reviewers: Phyx, simonmar, goldfire, bgamari, austin, hvr, erikd Reviewed By: Phyx, simonmar, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2773
* Revert "Make globals use sharedCAF"Ben Gamari2016-11-301-22/+22
| | | | | This reverts commit 6f7ed1e51bf360621a3c2a447045ab3012f68575 due to breakage of the build on Windows.
* Make globals use sharedCAFMoritz Angermann2016-11-291-22/+22
| | | | | | | | | | | | | | | The use of globals is quite painful when multiple rts are loaded, e.g. when plugins are loaded, which bring in a second rts. The sharedCAF appraoch was employed for the FastStringTable; I've taken the libery to extend this to the other globals I could find. Reviewers: rwbarton, simonmar, austin, hvr, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2575
* Some minor linker cleanups.Tamar Christina2016-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Just some cleanups to some oddities I've noticed while investigating a linker issue. Particularly the dll name returned by `findSysDll` was decorated. So foo.dll is returned. We make it `foo.dll.dll` and later drop one `.dll` when passed to `addDll` which expects it without extension, but still tries the name *as is* which is why it worked. This should be slightly faster, since we don't try 4 loads before we succeed. Test Plan: ./validate Reviewers: austin, hvr, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2680
* Align GHCi's library search order more closely with LDsTamar Christina2016-10-311-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Given a static library and an import library in the same folder. e.g. ``` libfoo.a libfoo.dll.a ``` running `ghci -lfoo` we should prefer the import library `libfoo.dll.a` over `libfoo.a` because we prefer having to just load the DLL. And not having to do any linking. This also more closely emulated the behaviour of LD, which has a search order of ``` libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll ``` Test Plan: ./validate Reviewers: RyanGlScott, austin, hvr, bgamari, erikd, simonmar Reviewed By: RyanGlScott Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2651 GHC Trac Issues: #12771
* Add and use a new dynamic-library-dirs field in the ghc-pkg infoDuncan Coutts2016-10-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Build systems / package managers want to be able to control the file layout of installed libraries. In general they may want/need to be able to put the static libraries and dynamic libraries in different places. The ghc-pkg library regisrtation needs to be able to handle this. This is already possible in principle by listing both a static lib dir and a dynamic lib dir in the library-dirs field (indeed some previous versions of Cabal did this for shared libs on ELF platforms). The downside of listing both dirs is twofold. There is a lack of precision, if we're not careful with naming then we could end up picking up the wrong library. The more immediate problem however is that if we list both directories then both directories get included into the ELF and Mach-O shared object runtime search paths. On ELF this merely slows down loading of shared libs (affecting prog startup time). On the latest OSX versions this provokes a much more serious problem: that there is a rather low limit on the total size of the section containing the runtime search path (and lib names and related) and thus listing any unnecessary directories wastes the limited space. So the solution in this patch is fairly straightforward: split the static and dynamic library search paths in the ghc-pkg db and its use within ghc. This is a traditional solution: pkg-config has the same static / dynamic split (though it describes in in terms of private and public, but it translates into different behaviour for static and dynamic linking). Indeed it would make perfect sense to also have a static/dynamic split for the list of the libraries to use i.e. to have dynamic variants of the hs-libraries and extra-libraries fields. These are not immediately required so this patch does not add it, but it is a reasonable direction to follow. To handle compatibility, if the new dynamic-library-dirs field is not specified then its value is taken from the library-dirs field. Contains Cabal submodule update. Test Plan: Run ./validate Get christiaanb and carter to test it on OSX Sierra, in combination with Cabal/cabal-install changes to the default file layout for libraries. Reviewers: carter, austin, hvr, christiaanb, bgamari Reviewed By: christiaanb, bgamari Subscribers: ezyang, Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2611 GHC Trac Issues: #12479
* Distinguish between UnitId and InstalledUnitId.Edward Z. Yang2016-10-081-12/+15
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Annotate initIfaceCheck with usage information.Edward Z. Yang2016-08-211-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Kill two instances of uniqSetToListBartosz Nitka2016-06-071-9/+8
| | | | | | | There should be no performance impact of switching to the deterministic set here. GHC Trac: #4012
* Use UniqDFM for HomePackageTableBartosz Nitka2016-06-061-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This isn't strictly necessary for deterministic ABIs. The results of eltsHpt are consumed in two ways: 1) they determine the order of linking 2) if you track the data flow all the family instances get put in FamInstEnvs, so the nondeterministic order is forgotten. 3) same for VectInfo stuff 4) same for Annotations The problem is that I haven't found a nice way to do 2. in a local way and 1. is nice to have if we went for deterministic object files. Besides these maps are keyed on ModuleNames so they should be small relative to other things and the overhead should be negligible. As a bonus we also get more specific names. Test Plan: ./validate Reviewers: bgamari, austin, hvr, ezyang, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2300 GHC Trac Issues: #4012
* Use UniqDSet for finding free names in the LinkerBartosz Nitka2016-06-021-3/+4
| | | | | | | | | | | | | | | | | | This is not necessary for determinism, but it's a choice between making this deterministic and using `nonDetEltsUFM` and a comment explaining that it doesn't matter. Test Plan: ./validate Reviewers: austin, hvr, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2295 GHC Trac Issues: #4012
* Add Windows import library support to the Runtime LinkerTamar Christina2016-04-171-16/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Print which warning-flag controls an emitted warningMichael Walker2016-02-251-3/+8
| | | | | | | | | | | | | | | | | Both gcc and clang tell which warning flag a reported warning can be controlled with, this patch makes ghc do the same. More generally, this allows for annotated compiler output, where an optional annotation is displayed in brackets after the severity. This also adds a new flag `-f(no-)show-warning-groups` to control whether to show which warning-group (such as `-Wall` or `-Wcompat`) a warning belongs to. This flag is on by default. This implements #10752 Reviewed By: quchen, bgamari, hvr Differential Revision: https://phabricator.haskell.org/D1943
* Remote GHCi: parallelise BCO serializationSimon Marlow2016-02-021-2/+2
| | | | | | | | | | | | | | | | | | | Summary: Serialization of BCOs is slow, but we can parallelise it when using ghci -j<n>. It parallelises nicely, saving multiple seconds off the link time in a large example I have. Test Plan: * validate * `ghci -fexternal-interpreter` in `nofib/real/anna` Reviewers: niteria, bgamari, ezyang, austin, hvr, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1877 GHC Trac Issues: #11100
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-181-17/+17
| | | | | | | | | | | | | | | | | | | | Summary: In the past the canonical way for constructing an SDoc string literal was the composition `ptext . sLit`. But for some time now we have function `text` that does the same. Plus it has some rules that optimize its runtime behaviour. This patch takes all uses of `ptext . sLit` in the compiler and replaces them with calls to `text`. The main benefits of this patch are clener (shorter) code and less dependencies between module, because many modules now do not need to import `FastString`. I don't expect any performance benefits - we mostly use SDocs to report errors and it seems there is little to be gained here. Test Plan: ./validate Reviewers: bgamari, austin, goldfire, hvr, alanz Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1784
* Link command line libs to temp soPeter Trommler2016-01-151-1/+13
| | | | | | | | | | | | | | | | | | | Symbols in libraries specified on the GHCis command line are not available to compiled modules because shared libraries are loaded with local scope. So we link all libraries specified on the command line into each temporary shared library. Test Plan: validate Reviewers: simonmar, hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1631 GHC Trac Issues: #10458
* Enable stack traces with ghci -fexternal-interpreter -profSimon Marlow2016-01-081-21/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The main goal here is enable stack traces in GHCi. After this change, if you start GHCi like this: ghci -fexternal-interpreter -prof (which requires packages to be built for profiling, but not GHC itself) then the interpreter manages cost-centre stacks during execution and can produce a stack trace on request. Call locations are available for all interpreted code, and any compiled code that was built with the `-fprof-auto` familiy of flags. There are a couple of ways to get a stack trace: * `error`/`undefined` automatically get one attached * `Debug.Trace.traceStack` can be used anywhere, and prints the current stack Because the interpreter is running in a separate process, only the interpreted code is running in profiled mode and the compiler itself isn't slowed down by profiling. The GHCi debugger still doesn't work with -fexternal-interpreter, although this patch gets it a step closer. Most of the functionality of breakpoints is implemented, but the runtime value introspection is still not supported. Along the way I also did some refactoring and added type arguments to the various remote pointer types in `GHCi.RemotePtr`, so there's better type safety and documentation in the bridge code between GHC and ghc-iserv. Test Plan: validate Reviewers: bgamari, ezyang, austin, hvr, goldfire, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1747 GHC Trac Issues: #11047, #11100
View Lorry Controller Status