summaryrefslogtreecommitdiff
path: root/compiler/ghci/Linker.hs
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Don't drop last char of file if -osuf contains dotThomas Miedema2015-12-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given: * `file = "foo.a.b"` * `osuf = ".a.b"` -- Note the initial dot. * `new_osuf = "c"` Before (bad, the last character of the filename is dropped): `dropTail (length osuf + 1) file <.> new_osuf == "fo.c"` After (good): `stripExtension osuf file <.> new_osuf` == "foo.c" This regression was introduced in commit c489af73 (#5554). That commit fixed a similar but different bug, and care has been taken to not reintroduce it (using the the newly introduced `System.Filepath.stripExtension`). Given: * `file = "foo.a.b"` * `osuf = "a.b"` * `new_osuf = "c"` Before c489af73 (bad, the full suffix should get replaced): `replaceExtension file new_osuf == "foo.a.c"` After c489af73 (good): `dropTail (length osuf + 1) file <.> new_osuf == "foo.c"` After this commit (still good): `stripExtension osuf file <.> new_osuf == "foo.c"` Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1692 GHC Trac Issues: #9760
* Maintain cost-centre stacks in the interpreterSimon Marlow2015-12-211-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Breakpoints become SCCs, so we have detailed call-stack info for interpreted code. Currently this only works when GHC is compiled with -prof, but D1562 (Remote GHCi) removes this constraint so that in the future call stacks will be available without building your own GHCi. How can you get a stack trace? * programmatically: GHC.Stack.currentCallStack * I've added an experimental :where command that shows the stack when stopped at a breakpoint * `error` attaches a call stack automatically, although since calls to `error` are often lifted out to the top level, this is less useful than it might be (ImplicitParams still works though). * Later we might attach call stacks to all exceptions Other related changes in this diff: * I reduced the number of places that get ticks attached for breakpoints. In particular there was a breakpoint around the whole declaration, which was often redundant because it bound no variables. This reduces clutter in the stack traces and speeds up compilation. * I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few other small cleanups Test Plan: validate Reviewers: ezyang, bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1595 GHC Trac Issues: #11047
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-242/+302
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (Apologies for the size of this patch, I couldn't make a smaller one that was validate-clean and also made sense independently) (Some of this code is derived from GHCJS.) This commit adds support for running interpreted code (for GHCi and TemplateHaskell) in a separate process. The functionality is experimental, so for now it is off by default and enabled by the flag -fexternal-interpreter. Reaosns we want this: * compiling Template Haskell code with -prof does not require building the code without -prof first * when GHC itself is profiled, it can interpret unprofiled code, and the same applies to dynamic linking. We would no longer need to force -dynamic-too with TemplateHaskell, and we can load ordinary objects into a dynamically-linked GHCi (and vice versa). * An unprofiled GHCi can load and run profiled code, which means it can use the stack-trace functionality provided by profiling without taking the performance hit on the compiler that profiling would entail. Amongst other things; see https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details. Notes on the implementation are in Note [Remote GHCi] in the new module compiler/ghci/GHCi.hs. It probably needs more documenting, feel free to suggest things I could elaborate on. Things that are not currently implemented for -fexternal-interpreter: * The GHCi debugger * :set prog, :set args in GHCi * `recover` in Template Haskell * Redirecting stdin/stdout for the external process These are all doable, I just wanted to get to a working validate-clean patch first. I also haven't done any benchmarking yet. I expect there to be slight hit to link times for byte code and some penalty due to having to serialize/deserialize TH syntax, but I don't expect it to be a serious problem. There's also lots of low-hanging fruit in the byte code generator/linker that we could exploit to speed things up. Test Plan: * validate * I've run parts of the test suite with EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th. There are a few failures due to the things not currently implemented (see above). Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1562
* DynFlags: remove Opt_StaticThomas Miedema2015-12-151-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | There are currently 2 different ways to test for a static or dynamic build: * Test if WayDyn is in ways * Test if Opt_Static is set The problem is that these can easily go out of sync, especially when using the GHC API. This commit replaces all queries of Opt_Static with an equivalent query of WayDyn. This would have prevented bug #8294 and fixes #11154. Reviewers: hvr, austin, bgamari Reviewed By: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1607 GHC Trac Issues: #10636
* Fix archive loading on Windows by the runtime loaderTamar Christina2015-11-171-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The runtime loader is unable to find archive files `.a` shipping with the inplace `GCC`. It seems the issue is caused by `findArchive` being unable to find any archives that are shipped using the in-place `GCC`. - It works on Linux because `findArchive` would search the standard Linux include path. - It works during compilation because `GCC` can find it's own libraries (we explicitly tell it where to look for libraries using the `gcc` wrapper around `realgcc`) So fixing the issue means using `searchForLibUsingGcc` in `findArchive` as well, which will then find the correct file. The reason for the error as it is, is because if we can't locate the library using any of the methods we have, we assume it is a system dll, or something on the system search path. e.g. if trying to load `kernel32.dll`. There is a slight issue in that the `GHCi` code (incorrectly) favors `static archives` over `dynamic` ones ``` findDll `orElse` findArchive `orElse` tryGcc `orElse` tryGccPrefixed `orElse` assumeDll ``` This has the unwanted effect of when `kernel32` is specified as a lib, it will try to load `kernel32.a` instead of `kernel32.dll`. To solve this I have added another search function that is able to search the Windows search paths using `SearchPath` in order to find if it is a dll on the system search path. The new search order is: ``` findDll `orElse` findSysDll `orElse` tryGcc `orElse` findArchive `orElse` assumeDll ``` (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at top level) Test Plan: ./validate added new windows tests T3242 Reviewers: thomie, erikd, hvr, austin, bgamari Reviewed By: thomie, erikd, bgamari Differential Revision: https://phabricator.haskell.org/D1455 GHC Trac Issues: #3242
* Allow the GHCi Linker to resolve related dependencies when loading DLLsTamar Christina2015-11-071-35/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's that are not on the standard Windows load path: 1. The directory from which the application loaded. 2. The current directory. 3. The system directory. Use the GetSystemDirectory function to get the path of this directory. 4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. 6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the AppPaths registry key. The App Paths key is not used when computing the DLL search path. So what this means is given two DLLs `A` and `B` and `B` depending on `A`. If we put both DLLs into a new folder bin and then call GHC with: `ghc -L$(PWD)/bin -lB` the loading will fail as the Windows loader will try to load the dependency of `B` and fail since it cannot find `A`. *IMPORTANT* this patch drops XP Support. The APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has not been installed on certain machines. For those machines I display a warning and temporarily expand the `PATH` to allow it to load. This patch will make sure that paths provided by the user with `-L` *and* the folder in which a DLL is found are added to the search path. It does so using one of two methods depending upon how new of a Windows version we are running on: - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`. The order of which these directories are searched is nondeterministic. - If the APIs are not available it means that we're running on a pretty old unpatched machine. But if it's being used in an environment with no internet access it may be the case. So if the APIs are not available we temporarily extend the `PATH` with the directories. A warning is also displayed to the user informing them that the linking may fail, and if it does, install the needed patch. The `PATH` variable has limitations. Test Plan: ./validate Added two new test T10955 and T10955dyn Reviewers: erikd, bgamari, thomie, hvr, austin Reviewed By: erikd, thomie Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1340 GHC Trac Issues: #10955
* Make GHCi & TH work when the compiler is built with -profSimon Marlow2015-11-071-32/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Amazingly, there were zero changes to the byte code generator and very few changes to the interpreter - mainly because we've used good abstractions that hide the differences between profiling and non-profiling. So that bit was pleasantly straightforward, but there were a pile of other wibbles to get the whole test suite through. Note that a compiler built with -prof is now like one built with -dynamic, in that to use TH you have to build the code the same way. For dynamic, we automatically enable -dynamic-too when TH is required, but we don't have anything equivalent for profiling, so you have to explicitly use -prof when building code that uses TH with a profiled compiler. For this reason Cabal won't work with TH. We don't expect to ship a profiled compiler, so I think that's OK. Test Plan: validate with GhcProfiled=YES in validate.mk Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang Reviewed By: ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1407 GHC Trac Issues: #4837, #545
* Rename package key to unit ID, and installed package ID to component ID.Edward Z. Yang2015-10-141-11/+11
| | | | | | Comes with Haddock submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Update Cabal to HEAD, IPID renamed to Component ID.Edward Z. Yang2015-10-141-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit contains a Cabal submodule update which unifies installed package IDs and package keys under a single notion, a Component ID. We update GHC to keep follow this unification. However, this commit does NOT rename installed package ID to component ID and package key to unit ID; the plan is to do that in a companion commit. - Compiler info now has "Requires unified installed package IDs" - 'exposed' is now expected to contain unit keys, not IPIDs. - Shadowing is no more. We now just have a very simple strategy to deal with duplicate unit keys in combined package databases: if their ABIs are the same, use the latest one; otherwise error. Package databases maintain the invariant that there can only be one entry of a unit ID. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1184 GHC Trac Issues: #10714
* Add short library names support to Windows linkerTamar Christina2015-10-101-3/+7
| | | | | | | | | | | | | | | Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc to pass -L to all components by using -B instead. These two fix shortnames linking on windows. re-enabled tests: ghcilink003, ghcilink006 and T3333 Added two tests: load_short_name and enabled T1407 on windows. Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1310 GHC Trac Issues: #9878, #1407, #1883, #5289
* Revert "Revert "Revert "Support for multiple signature files in scope."""Edward Z. Yang2015-09-211-30/+16
| | | | This reverts commit 214596de224afa576a9c295bcf53c6941d6892e0.
* Switch from recording IsBootInterface to recording full HscSource.Edward Z. Yang2015-07-221-1/+1
| | | | | | Note: ModIface format change is BC, no need to recompile. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Revert "Revert "Support for multiple signature files in scope.""Edward Z. Yang2015-07-201-16/+30
| | | | | | | This reverts commit bac927b9770ff769128b66d13a3e72bf5a9bc514. As it turns out, we need these commits for separate compilation and accurate dependency tracking. So back in they go!
* Revert "Support for multiple signature files in scope."Edward Z. Yang2015-06-111-30/+16
| | | | This reverts commit a7524eaed33324e2155c47d4a705bef1d70a2b5b.
* In ghci linker, link against all previous temp sos (#10322)Reid Barton2015-06-011-11/+11
| | | | | | | | | | | The OS X dlopen() appears to only resolve undefined symbols in the direct dependencies of the shared library it is loading. Reviewed By: trommler, austin Differential Revision: https://phabricator.haskell.org/D852 GHC Trac Issues: #10322
* Revert "In ghci linker, link against all previous temp sos (#10322)"Austin Seipp2015-05-191-11/+11
| | | | | | This reverts commit b0b11ad93cf8470caed572dc16e5cf91304fa355. It apparently made Harbormaster sad.
* In ghci linker, link against all previous temp sos (#10322)Reid Barton2015-05-191-11/+11
| | | | | | | | | | | The OS X dlopen() appears to only resolve undefined symbols in the direct dependencies of the shared library it is loading. Reviewed By: trommler, austin Differential Revision: https://phabricator.haskell.org/D852 GHC Trac Issues: #10322
* Support for multiple signature files in scope.Edward Z. Yang2015-04-071-16/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A common pattern when programming with signatures is to combine multiple signatures together (signature linking). We achieve this by making it not-an-error to have multiple, distinct interface files for the same module name, as long as they have the same backing implementation. When a user imports a module name, they get ALL matching signatures dumped into their scope. On the way, I refactored the module finder code, which now distinguishes between exact finds (when you had a 'Module') and regular finds (when you had a 'ModuleName'). I also refactored the package finder code to use a Monoid instance on LookupResult to collect together various results. ToDo: At the moment, if a signature is declared in the local package, it completely overrides any remote signatures. Eventually, we'll want to also pull in the remote signatures (or even override the local signature, if the full implementation is available.) There are bunch of ToDos in the code for what to do once this is done. ToDo: At the moment, whenever a module name lookup occurs in GHCi and we would have seen a signature, we instead continue and return the Module for the backing implementation. This is correct for most cases, but there might be some situations where we want something a little more fine-grained (e.g. :browse should only list identifiers which are available through the in-scope signatures, and not ALL of them.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, hvr, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D790 GHC Trac Issues: #9252
* Refactor: follow hlint suggestions in Linker.hsThomas Miedema2015-03-191-10/+6
| | | | | | Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D739
View Lorry Controller Status