summaryrefslogtreecommitdiff
path: root/compiler/main/SysTools.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* Introduce putLogMsgBen Gamari2017-03-151-2/+2
| | | | | | | | | | | | | 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
* Correct Windows libdir assumptions.Tamar Christina2017-02-231-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC and ghc-pkg make some pretty hard assumptions about where they're running on Windows. They assume that they are always running from `foo/bin/ghc.exe` and that to find the `lib` folder they can drop `bin/ghc.exe` from the base path and append `lib`. This is already false for the testsuite, which when testing thenbindist has one test which puts the binaries in `inplace/test spaces`. For some reason before this was either being skipped or mysteriously passing. But as of `2017.02.11` our luck ran out. the testsuite triggers a failure such as those in #13310 Let's soften the assumption and just check that `../lib` exists instead. 80 chars Test Plan: ./validate Reviewers: austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3158
* Avoid repeated list elem checksDavid Feuer2017-02-111-2/+5
| | | | | | | | | | | | Convert a list to a set before testing membership multiple times. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3111
* Ditch static flagsSylvain Henry2017-02-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Bump Win32 version.Ben Gamari2017-01-241-2/+6
| | | | | | | | | | | | | | | | | | | | | | Bump the version of `Win32` to `2.5.0.0` which is a major update and includes fixes for wrong alignments and wrong 64-bit types. Strangely enough this also seems to resolve #12713, where `T10858` was failing due to too-low allocations. The underlying type aliases have changed, so there is a potential for user programs not to compile anymore, but the types were incorrect. This also requires a bump in the `directory`, `Cabal`, and `process` submodules. Original author: Tamar Christina <tamar@zhox.com> Test Plan: ./validate Reviewers: bgamari, RyanGlScott, austin Subscribers: hvr, RyanGlScott, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2938
* Always use -Xlinker for -rpathBartosz Nitka2017-01-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Use latin1 code page on Windows for response files.Tamar Christina2017-01-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: D2917 added a change that will make paths on Windows response files use DOS 8.3 shortnames to get around the fact that `libiberty` assumes a one byte per character encoding. This is actually not the problem, the actual problem is that GCC on Windows doesn't seem to support Unicode at all. This comes down to how unicode characters are handled between POSIX and Windows. On Windows, Unicode is only supported using a multibyte character encoding such as `wchar_t` with calls to the appropriate wide version of APIs (name post-fixed with the `W` character). On Posix I believe the standard `char` is used and based on the value it is decoded to the correct string. GCC doesn't seem to make calls to the Wide version of the Windows APIs, and even if it did, it's character representation would be wrong. So I believe GCC just does not support utf-8 paths on Windows. So the hack in D2917 is the only way to get Unicode support. The problem is however that `GCC` is not the only tool with this issue and we don't use response files for every invocation of the tools. Most of the tools probably don't support it. Furthermore, DOS 8.1 shortnames only exist when the path or file physically exists on disk. We pass lots of paths to GCC that don't exist yet, like the output file. D2917 works around this by splitting the path from the file and try shortening that. But this may not always work. In short, even if we do Unicode correctly (which we don't atm, the GCC driver we build uses `char` instead of `wchar_t`) we won't be able to compile using unicode paths that need to be passed to `GCC`. So not sure about the point of D2917. What we can do is support the most common non-ascii characters by writing the response files out using the `latin1` code page. Test Plan: compile + make test TEST=T12971 Reviewers: austin, bgamari, erikd Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2942 GHC Trac Issues: #12971
* Pass -no-pie to GCCBen Gamari2016-11-111-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be default in their GCC packaging. This breaks our abuse of GCC as a linker which requires that we pass -Wl,-r, which is incompatible with PIE (since the former implies that we are generating a relocatable object file and the latter an executable). This is a second attempt at D2691. This attempt constrasts with D2691 in that it preserves the "does gcc support -no-pie" flag in settings, allowing this to be reconfigured by `configure` during installation of a binary distribution. Thanks for @rwbarton for drawing attention to this issue. Test Plan: Validate Reviewers: austin, hvr, erikd Reviewed By: erikd Subscribers: thomie, rwbarton, erikd Differential Revision: https://phabricator.haskell.org/D2693 GHC Trac Issues: #12759
* Revert "Pass -no-pie to GCC"Ben Gamari2016-11-101-13/+0
| | | | | | This reverts commit bae4a55b1fb403f610b4b55a1b6fb3f03e9c2026. This will be superceded by D2693.
* Pass -no-pie to GCCBen Gamari2016-11-101-0/+13
| | | | | | | | | | | | | | | | | | Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be default in their GCC packaging. This breaks our abuse of GCC as a linker which requires that we pass -Wl,-r, which is incompatible with PIE (since the former implies that we are generating a relocatable object file and the latter an executable). Test Plan: Validate Reviewers: hvr, austin Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D2691 GHC Trac Issues: #12759
* Omit unnecessary linker flagsSimon Marlow2016-11-031-19/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This omits -L and -l flags from the linker command line that shouldn't be necessary because GHC will already add them via the -package-id flags we pass. This also reverts part of 90538d86af579595987826cd893828d6f379f35a that rearranges the linker command line and causes some knock-on problems (see D2618). Test Plan: validate (need to validate on Windows too) Reviewers: Phyx, bgamari, niteria, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2639 GHC Trac Issues: #12738
* Add -Wcpp-undef warning flagErik de Castro Lopo2016-10-221-3/+2
| | | | | | | | | | | | | | | | | | | | When enabled, this new warning flag passes `-Wundef` to the C pre-processor which causes the pre-processor to warn on uses of the `#if` directive on undefined identifiers. It is not currently enabled in any of the standard warning groups. Test Plan: Make sure the two tests pass on all major platforms. Reviewers: hvr, carter, Phyx, bgamari, austin Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2626 GHC Trac Issues: #12752
* Add and use a new dynamic-library-dirs field in the ghc-pkg infoDuncan Coutts2016-10-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-2/+2
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Use check stacking on Windows.Tamar Christina2016-10-011-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: #8870 added as a temporary work around a much higher initial reserve and committed stack space of 2mb. This is causing problems with other windows applications. The hack was supposed to be temporary untill we could emit `__chkstk` instructions. But GCC can emit stack checks automatically for us if `-fstack-check` is passed. This will then emit calls to `___chkstk_ms` before stack allocations. ``` 633de0: 48 83 e0 f0 and $0xfffffffffffffff0,%rax 633de4: e8 07 0c 0d 00 callq 7049f0 <___chkstk_ms> 633de9: 48 29 c4 sub %rax,%rsp ``` The hack is now no longer needed. Test Plan: ./validate Reviewers: austin, erikd, awson, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2535 GHC Trac Issues: #12186
* Allow building static libs.Moritz Angermann2016-06-251-0/+2
| | | | | | | | | | | | | | | | | | Summary: Commit 90538d86af579595987826cd893828d6f379f35a, seems to have broken static linking. The introduction of `argFixup` in `runLink` rearranges libs, and considers anything with an `-l` prefix or `.a` suffix a lib, which fails for libs that are just being linked together (e.g. `-o lib.a`). The proposed solution explicitly checks for the existance of the `-o` flag. Reviewers: rwbarton, erikd, Phyx, bgamari, austin Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2362
* Simplify readProcessEnvWithExitCode + set LANGUAGE=CThomas Miedema2016-06-141-39/+13
| | | | | | | | | | | | | | | | | | `readProcessEnvWithExitCode` was added in 4d4d07704ee78221607a18b8118294b0aea1bac4, to start an external process after making some modifications to the environment. Since then, the `process` library has exposed `readCreateProcessWithExitCode`, which allows for the refactoring we do here. Also change "en" to "C", as suggested in ticket:8825#comment:11. Reviewed by: trofi Differential Revision: https://phabricator.haskell.org/D2332 GHC Trac Issues: #8825
* Resolve symlinks when attempting to find GHC's lib folder on WindowsTamar Christina2016-04-171-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Systools makes some pretty hard assumptions about where GHC is on Windows. One of these is that ghc be in a folder named `bin` and that `../lib` exists. This pattern doesn't hold for symlinks as a link `C:\ghc-bin\` pointing to `C:\ghc\ghc-7.10.3\bin` will break this assumption. This patch resolves symlinks by finding where they point to and uses that location as the base for GHC. This uses an API that's been introduced in Vista. For older systems it falls back to the current behavior of not resolving symlinks. Test Plan: 1) Create symlink to GHC's bin folder. 2) Run GHC from that folder. Reviewers: austin, bgamari Reviewed By: austin Subscribers: #ghc_windows_task_force, thomie Differential Revision: https://phabricator.haskell.org/D2101 GHC Trac Issues: #11759
* Change runtime linker to perform lazy loading of symbols/sectionsTamar Christina2016-04-111-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Runtime Linker is currently eagerly loading all object files on all platforms which do not use the system linker for `GHCi`. The problem with this approach is that it requires all symbols to be found. Even those of functions never used/called. This makes the number of libraries required to link things like `mingwex` quite high. To work around this the `rts` was relying on a trick. It itself was compiled with `MingW64-w`'s `GCC`. So it was already linked against `mingwex`. As such, it re-exported the symbols from itself. While this worked it made it impossible to link against `mingwex` in user libraries. And with this means no `C99` code could ever run in `GHCi` on Windows without having the required symbols re-exported from the rts. Consequently this rules out a large number of packages on Windows. SDL2, HMatrix etc. After talking with @rwbarton I have taken the approach of loading entire object files when a symbol is needed instead of doing the dependency tracking on a per symbol basis. This is a lot less fragile and a lot less complicated to implement. The changes come down to the following steps: 1) modify the linker to and introduce a new state for ObjectCode: `Needed`. A Needed object is one that is required for the linking to succeed. The initial set consists of all Object files passed as arguments to the link. 2) Change `ObjectCode`'s to be indexed but not initialized or resolved. This means we know where we would load the symbols, but haven't actually done so. 3) Mark any `ObjectCode` belonging to `.o` passed as argument as required: ObjectState `NEEDED`. 4) During `Resolve` object calls, mark all `ObjectCode` containing the required symbols as `NEEDED` 5) During `lookupSymbol` lookups, (which is called from `linkExpr` and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded `ObjectCode` then load the `ObjectCode` on demand and return the address of the symbol. Otherwise produce an unresolved symbols error as expected. 6) On `unloadObj` we then change the state of the object and remove it's symbols from the `reqSymHash` table so it can be reloaded. This change affects all platforms and OSes which use the runtime linker. It seems there are no real perf tests for `GHCi`, but performance shouldn't be impacted much. We gain a lot of time not loading all `obj` files, and we lose some time in `lookupSymbol` when we're finding sections that have to be loaded. The actual finding itself is O(1) (Assuming the hashtnl is perfect) It also consumes slighly more memory as instead of storing just the address of a symbol I also store some other information, like if the symbol is weak or not. This change will break any packages relying on renamed POSIX functions that were re-named and re-exported by the rts. Any packages following the proper naming for functions as found on MSDN will work fine. Test Plan: ./validate on all platforms which use the Runtime linker. Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr Reviewed By: erikd Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar, rwbarton, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1805 GHC Trac Issues: #11223
* Print which warning-flag controls an emitted warningMichael Walker2016-02-251-2/+2
| | | | | | | | | | | | | | | | | 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
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-181-3/+3
| | | | | | | | | | | | | | | | | | | | 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
* LLVM backend: Show expected LLVM version in warnings/errorsÖmer Sinan Ağacan2015-12-181-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before: [1 of 1] Compiling Main ( Main.hs, Main.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... After: [1 of 1] Compiling Main ( Main.hs, Main.o ) You are using an unsupported version of LLVM! Currently only 3.7 is supported. We will try though... Before: [1 of 1] Compiling Main ( Main.hs, Main.o ) <no location info>: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt After: [1 of 1] Compiling Main ( Main.hs, Main.o ) <no location info>: error: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM 3.7 ghc-stage1: could not execute: opt Reviewers: austin, rwbarton, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1658
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Make GHC aware of OSAIX and AixLDHerbert Valerio Riedel2015-11-191-0/+4
| | | | | | | | | | | | | | GHC needs to be aware of targetting AIX because AIX requires some special handling for the toolchain (similiar to Solaris) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1501
* Implement function-sections for Haskell code, #8405Simon Brenner2015-11-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a flag -split-sections that does similar things to -split-objs, but using sections in single object files instead of relying on the Satanic Splitter and other abominations. This is very similar to the GCC flags -ffunction-sections and -fdata-sections. The --gc-sections linker flag, which allows unused sections to actually be removed, is added to all link commands (if the linker supports it) so that space savings from having base compiled with sections can be realized. Supported both in LLVM and the native code-gen, in theory for all architectures, but really tested on x86 only. In the GHC build, a new SplitSections variable enables -split-sections for relevant parts of the build. Test Plan: validate with both settings of SplitSections Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari Reviewed By: simonmar, thomie, bgamari Subscribers: hsyl20, erikd, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D1242 GHC Trac Issues: #8405
* Systools: read ELF section without calling readelfSylvain HENRY2015-11-111-28/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch tackles two issues: 1) GHC stores a "link info" string into a ELF section. Initially a section with type "note" was used but GHC didn't follow the ELF specification which specifies a record-based format for these sections. With D1375 we switched to a "progbits" section type for which there isn't any format constraint. This is an issue for D1242 which use GCC's --gc-sections which collects "unused" sections, such as our section containing link info... In this patch, we fall back to a section with type "note" but we respect the specified format. 2) Reading back the ELF section was done by parsing the result of a call to "readelf". Calling readelf is problematic because the program may not be available or it may be renamed on some platforms (see D1326). Moreover we have no garanty that its output layout will stay the same in future releases of readelf. Finally we would need to fix the parsing to support "note" sections because of 1. Instead, this patch proposes to use Data.Binary.Get to directly read the "link info" note into its section. ELF has a specification, hence it should work on every conforming platform. This patch "reverts" D1375, hence it supersedes D1432. It makes D1326 not necessary anymore. Test Plan: - recomp011 should pass (test that relinking is avoided when both "link info" match) - we should add a test for ELF objects with more than 0xff00 sections => added test "recomp015" - we should check that GAS generates 32-bit words with .int on every supported platform using ELF (or find a place where this is documented). harbomaster and I (@hsyl20) only tested on x86-64. On platforms where it is not true, it should make recomp011 fail. => tested to work on Linux/amd64, Solaris/i386 and OpenBSD/amd64 Reviewers: olsner, ony, thomie, kgardas, austin, bgamari Reviewed By: thomie, bgamari Subscribers: kgardas, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1381 GHC Trac Issues: #10974, #11022
* Use full name of LLVM program in error messageErik de Castro Lopo2015-11-041-1/+1
| | | | | | | | | | | | Previously something like `/usr/bin/opt-3.7` was being shortened to `opt-3` using the `takeBaseName` function. This shortened form is actually not correct. We should use `takeFileName` instead. Reviewers: bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1420
* Systools.hs: Improve detection of GCC and ClangErik de Castro Lopo2015-10-201-2/+2
| | | | | | | | | | | | Test Plan: Build on Debian using `--with-gcc=clang` Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1336 GHC Trac Issues: #10981
* Rename package key to unit ID, and installed package ID to component ID.Edward Z. Yang2015-10-141-4/+4
| | | | | | Comes with Haddock submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Switch to LLVM version 3.7Erik de Castro Lopo2015-10-141-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | Before this commit, GHC only supported LLVM 3.6. Now it only supports LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier do not work on AArch64/Arm64, but 3.7 does. Also: * Add CC_Ghc constructor to LlvmCallConvention. * Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with a single `supportedLlvmVersion` variable. * Get `supportedLlvmVersion` from version specified in configure.ac. * Drop llvmVersion field from DynFlags (no longer needed because only one version is supported). Test Plan: Validate on x86_64 and arm Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1320 GHC Trac Issues: #10953
* Fix broken validation Build 6564 and accepting a few other test resultsTamar Christina2015-10-031-1/+1
| | | | | | | | | | | | Test Plan: ./validate Reviewers: thomie, austin, bgamari Reviewed By: bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1304
* Prevent GHC from silently dying when preprocessor is not foundTamar Christina2015-10-031-10/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows preprocessor code calls `runInteractiveProcess` but does not check if an exception is thrown. `runInteractiveProcess` calls `CreateProcess` which when given a format the system loader does not know about will throw an exception. This is what makes #9399 fail. Ultimately we should not use any `CreateProcess` based calls but instead `ShellExecuteEx` as this would allow us to run applications that the shell knows about instead of just the loader. More details on #365. This patch removes `PhaseFailed` and throws `ProgramError` instead. `PhaseFailed` was largely unneeded since it never gave very useful information aside from the `errorcode` which was almost always `1`. `IOErrors` have also been eliminated and `GhcExceptions` thrown in their place wherever possible. Updates haddock submodule. Test Plan: `./validate` to make sure anything didn't break and `make TESTS="T365"` to test that an error is now properly thrown Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1256 GHC Trac Issues: #365
* DynFlags: remove unused sPgm_sysman (#8689)Thomas Miedema2015-09-161-3/+0
| | | | | | | | Something about a long deleted 'system manager' for the 'parallel system'. Also remove confusing comment in SysTools, that supposedly referred to sPgm_sysman. See commit 16d5d1c75c999677783c9c1bda519540fa9a6e58.
* Use a response file for linker command line arguments #10777Michael Snoyman2015-09-021-2/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Windows, we're constrained to 32k bytes total for command line arguments. When building large projects, this limit can be exceeded. This patch changes GHC to always use response files for linker arguments, a feature first used by Microsoft compilers and added to GCC (over a decade ago). Alternatives here include: * Only use this method on Windows systems * Check the length of the command line arguments and use that to decide whether to use this method I did not pursue either of these, as I believe it would make the patch more likely to break in less tested situations. Test Plan: Confirm that linking still works in general. Ideally: compile a very large project on Windows with this patch. (I am attempting to do that myself now, but having trouble getting the Windows build tool chain up and running.) Reviewers: goldfire, hvr, rwbarton, austin, thomie, bgamari, Phyx Reviewed By: thomie, bgamari, Phyx Subscribers: erikd, awson, #ghc_windows_task_force, thomie Differential Revision: https://phabricator.haskell.org/D1158 GHC Trac Issues: #8596, #10777
* SysTools: Fix whitespace in error messageBen Gamari2015-08-121-1/+1
|
* Upgrade GCC to 5.2.0 for Windows x86 and x86_64Tamar Christina2015-08-121-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add framework flags when linking a dynamic libraryChristiaan Baaij2015-08-051-1/+41
| | | | | | | | | | | | | | | | | | | | | | This fixes the GHC side of trac #10568. So `cabal install --ghc-options="-framework GLUT" GLUT` creates a correctly linked GLUT.dylib. We still need to explictly pass `--ghc-options="-framework GLUT"` because the Cabal side #10568 is not fixed. Update: the Cabal side of #10568 is fixed by [Cabal#2747](https://github.com/haskell/cabal/pull/2747) Test Plan: validate Reviewers: austin, rwbarton, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1115 GHC Trac Issues: #10568
* newTempName: Do not include pid in basenameJoachim Breitner2015-06-021-5/+14
| | | | | | | | | | | | | | | | | | | | | The filename of temporary files, especially the basename of C files, can end up in the output in some form, e.g. as part of linker debug information. In the interest of bit-wise exactly reproducible compilation (#4012), the basename of the temporary file no longer contains random information (it used to ontain the process id). This is ok, as the temporary directory used contains the pid (see getTempDir). This patch has been applied to the Debian package (version 7.10.1-5) and allowed a fully bit-wise reproducible build: https://reproducible.debian.net/rb-pkg/experimental/amd64/ghc.html Reviewed By: austin, rwbarton Differential Revision: https://phabricator.haskell.org/D910 GHC Trac Issues: #4012
* Replace hooks by callbacks in RtsConfig (#8785)Simon Marlow2015-04-071-8/+3
| | | | | | | | | | | | 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
* clarify --no-as-needed is only needed on ELFPeter Trommler2015-04-031-1/+10
| | | | | | | | | | | | | | | From the code it was not clear that `--no-as-needed` was not necessary on Windows. Add this fact and describe the fix for #10110 in a separate note. See audit for rGHC1b7f59769052fd8193c6acc561216e070d0ca335 raised by @thomie. Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D791 GHC Trac Issues: #10110
* Link temporary shared objects with `--no-as-needed`Peter Trommler2015-03-141-5/+14
| | | | | | | | | | | | | | | | | | | | | | Some ELF link editors default to `--as-needed` and record only those libraries in DT_NEEDED tags that are needed to resolve undefined symbols in the shared object to be created. In Template Haskell we rely on all symbols that were defined in modules compiled so far to be available in the current temporary shared object. To prevent the link editor from dropping the DT_NEEDED tag for the previously linked temporary shared object we need to override the link editors default and specify `--no-as-needed` on the command line. This is for GNU ld and GOLD ld. This addresses #10110 TODO: regression test Reviewed By: hvr Differential Revision: https://phabricator.haskell.org/D731
* Update process submoduleThomas Miedema2015-03-091-4/+5
| | | | | | | | | | | | | Summary: Rename `SysTools.readCreateProcess`. Functions `readCreateProcess` and `readCreateProcessWithExitCode` were added to `System.Process`, the former of which conflicts with `SysTools.readCreateProcess`. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D713
* Use strict atomicModifyIORef' (added in GHC 7.6).Edward Z. Yang2015-01-281-6/+6
| | | | | | | | | | | | Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D635
* Fix system linker on Mac OS XPeter Trommler2014-12-291-1/+19
| | | | | | | | | | | | | | | | | | | | | | Summary: Flag `-l:` is GNU ld specific and not supported by the Mac OS X link editor. So we create a temporary file name lib<tmpname>.<so_ext> and link with the standard -l<tmpname> option on Linux and OS X. Fixes #9875 Test Plan: validate on Mac OS X Reviewers: austin, hvr, ezyang Reviewed By: ezyang Subscribers: carter, thomie, ezyang Differential Revision: https://phabricator.haskell.org/D579 GHC Trac Issues: #9875
* LlvmCodeGen cross-compiling fixes (#9895)Erik de Castro Lopo2014-12-291-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: * Throw an error when cross-compiling without a target definition. When cross compiling via LLVM, a target 'datalayout' and 'triple' must be defined or LLVM will generate code for the compile host instead of the compile target. * Add aarch64-unknown-linux-gnu target. The datalayout and triple lines were found by using clang to compile a small C program and -emit-llvm to get the LLVM IR output. Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com> Test Plan: validate Reviewers: rwbarton, carter, hvr, bgamari, austin Reviewed By: austin Subscribers: carter, thomie, garious Differential Revision: https://phabricator.haskell.org/D585 GHC Trac Issues: #9895
* trac #9744, make program name and product version configurable through ↵Luite Stegeman2014-12-201-0/+2
| | | | | | | | | | | | | | | | | | | DynFlags/Settings Summary: This allows GHC API clients to use a package database and dynamic library names that do not clash with those of the host GHC This also updates the Haddock submodule. Reviewers: hvr, austin Reviewed By: austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D496
* compiler: de-lhs main/Austin Seipp2014-12-031-0/+1590
Signed-off-by: Austin Seipp <austin@well-typed.com>
View Lorry Controller Status