summaryrefslogtreecommitdiff
path: root/rts/ghc.mk
Commit message (Collapse)AuthorAgeFilesLines
* Remove -Waggregate-return when building RTSÖmer Sinan Ağacan2018-09-201-1/+0
| | | | | | | | | | | This causes slow validate build to fail (in Profiling.c:countTickss), and there's nothing wrong with struct returns. Reviewers: simonmar, bgamari, erikd Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5164
* rts: Disable -fkeep-inline-functions due to lack of support on ClangBen Gamari2018-07-311-2/+3
| | | | But keep it as a comment since it is quite useful yet not very discoverable.
* rts: More forceful cc debugging flagsBen Gamari2018-07-271-1/+3
| | | | | | | | | | Reviewers: simonmar, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4999
* Make dtrace enabled GHC work as a bootstrap compiler on FreeBSDBen Gamari2018-06-151-6/+26
| | | | | | | | | | | | Fixes #15040. Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4772
* Revert "rts: Compile with gcc -Og"Ben Gamari2018-05-141-1/+1
| | | | This reverts commit d4abd031f6e8c2fa01f8949f60d8a02cca513804.
* rts: Compile with gcc -OgBen Gamari2018-05-131-1/+1
| | | | | | | | | | | | | | | This optimisation level is specifically designed to provide the benefits of optimisation without the obfuscation that sometimes results. Test Plan: Validate Reviewers: simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4675
* rts: Don't disable formatting warning in RetainerSet.cBen Gamari2018-05-011-1/+0
| | | | This really shouldn't be necessary.
* Remove MAX_PATH restrictions from RTS, I/O manager and various utilitiesTamar Christina2018-03-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This shims out fopen and sopen so that they use modern APIs under the hood along with namespaced paths. This lifts the MAX_PATH restrictions from Haskell programs and makes the new limit ~32k. There are only some slight caveats that have been documented. Some utilities have not been upgraded such as lndir, since all these things are different cabal packages I have been forced to copy the source in different places which is less than ideal. But it's the only way to keep sdist working. Test Plan: ./validate Reviewers: hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #10822 Differential Revision: https://phabricator.haskell.org/D4416
* ghc-prim: Emulate C11 atomics when not availableBen Gamari2018-02-031-0/+2
| | | | | | | | | | | | | | | | | | GCC's __sync primitives apparently "usually" imply a full barrier, meaning they can be used to emulate the more precise C11 atomics albeit with a loss of efficiency. This restores compatibility with GCC 4.4. This partially reverts commit 59de290928e6903337f31c1f8107ac8a98ea145d. Test Plan: Validate on Centos Reviewers: hvr, simonmar, trommler Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #14244 Differential Revision: https://phabricator.haskell.org/D4364
* RTS: Disable warnings in ffi.hPeter Trommler2017-11-151-1/+8
| | | | | | | | | | | | | | | | | | | | | The update of GHC's in-tree libffi causes warnings about undefined macros and hence validate fails. Also mark broken tests that have a ticket. Fixes #14353 Test Plan: ./validate (on AIX and powerpc if possible) Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie GHC Trac Issues: #14353, #11259, #14455, #11261 Differential Revision: https://phabricator.haskell.org/D4181
* Update autoconf test for gcc to require 4.7 and upPeter Trommler2017-11-061-6/+0
| | | | | | | | | | | | | | | | | | | Fixing #14244 required the newer gcc atomic built-ins that are provided from 4.7 and up. This updates the test to check for minimum gcc version 4.7. The version tests for 3.4 (!), 4.4, and 4.6 are no longer needed and can be removed. This makes the build system simpler. Test Plan: validate Reviewers: austin, bgamari, hvr, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4165
* FreeBSD dtrace probe supportBen Gamari2017-10-161-7/+33
| | | | | | | | | | Reviewers: austin, hvr, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: snowleopard, raichoo, rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3994
* Replace hashing function for string keys implementation with xxhashTamar Christina2017-09-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing profiling on startup time of ghci on Windows, both cold and startup loading static LLVM libs, the profiler is showing a glaring red spot on the division operation of the the hashStr function. In fact profiling shows 14% of the time is spent hashing the keys. So I am replacing the hash function with xxHash which is a very fast non-crypto hash. It's faster than MurMurHash which node etc use. It also passes SMHasher. I can provide if required the collected raw data. But from analysis done on the keys, xxHash does not introduce more collisions than before, the amount splits seem about the same and the distributions among the buckets are slightly more uniform than before. However the runtime dropped enough to remove the function completely from the profiler's report. There's also a noticeable improvement in responsiveness. xxHash is BSD licensed and can be found https://github.com/Cyan4973/xxHash Test Plan: ./validate Reviewers: austin, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13165 Differential Revision: https://phabricator.haskell.org/D3909
* Add gen-dll as replacement for dll-splitTamar Christina2017-08-291-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This tool can be used to generate dll's for any list of object files given to it. It will then repartition them automatically to fit within a dll and generates as many dll's as needed to do this. Cyclic dependencies between these generated dlls are handle automatically so there is no need to tell it how to partition. It is also a lot more general than `dll-split` as it is able to split any package not just `libGHC`. It also uses a trick using GNU style import libraries to hide the splitting from the rest of the pipeline. Which means come linking time you don't need to know which dll contains what symbol or how many split dlls were created. The import libraries are by default created with libtool. However since libtool is BFD based it is very slow. So if present and detected by configure the `genlib` tool from the msys2 project is used. This makes a difference of about ~45 minutes when compiling. To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`. More detailed explaination of the process can be found here https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force GHC Trac Issues: #5987 Differential Revision: https://phabricator.haskell.org/D3883
* rts: Enable USDT probes object on LinuxBen Gamari2017-08-171-1/+5
| | | | | | | | | | | | Summary: The dtrace utility shipped with Debian expects this. Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3829
* rts: Don't build StgCRunAsm.S if unregisterisedBen Gamari2017-05-111-0/+3
| | | | | | | | | | | | | | | | | StgCRunAsm.S provides StgCRun on powerpc64le platforms when registerised. However, in the unregisterised setting we use the mini-interpreter and consequently shouldn't build StgCRunAsm.S lest we get duplicate symbols. Test Plan: Build unregisterised compiler on AIX. Reviewers: hvr, trommler, austin, simonmar Reviewed By: trommler, simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3560
* Enable new warning for fragile/incorrect CPP #if usageErik de Castro Lopo2017-04-281-1/+4
| | | | | | | | | | | | | | | | The C code in the RTS now gets built with `-Wundef` and the Haskell code (stages 1 and 2 only) with `-Wcpp-undef`. We now get warnings whereever `#if` is used on undefined identifiers. Test Plan: Validate on Linux and Windows Reviewers: austin, angerman, simonmar, bgamari, Phyx Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3278
* rts: tweak cross-compilation to mingw32Sergei Trofimovich2017-04-231-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found the problem on x86_64-linux host where I tried to cross-compile GHC to windows as: $ ./configure --target=i686-w64-mingw32 \ Windres=i686-w64-mingw32-windres \ DllWrap=i686-w64-mingw32-dllwrap As a result build failed as POSIX bits of RTS. For example 'rts/posix/OSMem.c' contains unix-specific mmap() syscalls and constants and thus can't be compiled by i686-w64-mingw32 toolchain. It's caused by the following part of 'rts/ghc.mk': ifeq "$(HostOS_CPP)" "mingw32" ALL_DIRS += win32 else ALL_DIRS += posix endif In our case _CPP variables are defined this way (project.mk): BuildOS_CPP = linux HostOS_CPP = linux TargetOS_CPP = mingw32 RTS should never be built for 'BuildOS' or 'HostOS' as it's always built by ghc-stage1 (targeted at TargetOS). The change is to flip 'HostOS_CPP' to 'TargetOS_CPP' in 'rts/ghc.mk'. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* Revert "Enable new warning for fragile/incorrect CPP #if usage"Ben Gamari2017-04-051-4/+1
| | | | | | | | This is causing too much platform dependent breakage at the moment. We will need a more rigorous testing strategy before this can be merged again. This reverts commit 7e340c2bbf4a56959bd1e95cdd1cfdb2b7e537c2.
* Enable new warning for fragile/incorrect CPP #if usageErik de Castro Lopo2017-04-051-1/+4
| | | | | | | | | | | | | | | | The C code in the RTS now gets built with `-Wundef` and the Haskell code (stages 1 and 2 only) with `-Wcpp-undef`. We now get warnings whereever `#if` is used on undefined identifiers. Test Plan: Validate on Linux and Windows Reviewers: austin, angerman, simonmar, bgamari, Phyx Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3278
* Drop copy step from the rts/ghc.mkMoritz Angermann2017-02-281-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Recently I've used a different build system for building the rts (Xcode). And in doing so, I looked through the rts/ghc.mk to figure out how to build the rts. In general it's quite straight forward to just compile all the c files with the proper flags. However there is one rather awkward copy step that copies some files for special handling for the rts way. I'm wondering if the proposed solution in this diff is better or worse than the current situation? The idea is to keep the files, but use #includes to produce identical files with just an additional define. It does however produce empty objects for non threaded ways. Reviewers: ezyang, bgamari, austin, erikd, simonmar, rwbarton Reviewed By: bgamari, simonmar, rwbarton Subscribers: rwbarton, thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3237
* Apply SplitSections to all C compilationsSimon Brenner2017-02-111-4/+0
| | | | | | | | | | | | | | | | | | | Previously this was added only to the RTS's C files (those are the bulk of it though), but there are C bits in ghc-prim, integer-gmp and base too. Followup for #8405, allows the large table of character properties in base to be stripped when not used. Test Plan: validate Reviewers: austin, bgamari, simonmar Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3121
* Typos in commentsGabor Greif2016-10-211-1/+1
|
* Fix detection and use of `USE_LIBDW`Erik de Castro Lopo2016-06-011-8/+0
| | | | | | | | | | | | Test Plan: Configure/build with and without --enable-libdw Reviewers: trofi, hvr, austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2276
* Runtime linker: Break m32 allocator out into its own fileErik de Castro Lopo2016-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | This makes the code a little more modular and allows the removal of some CPP hackery. By providing dummy implementations of of the `m32_*` functions (which simply call `errorBelch`) it means that the call sites for these functions are syntax checked even when `RTS_LINKER_USE_MMAP` is `0`. Also changes some size parameter types from `unsigned int` to `size_t`. Test Plan: Validate on Linux, OS X and Windows Reviewers: Phyx, hsyl20, bgamari, simonmar, austin Reviewed By: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2237
* Rework CC/CC_STAGE0 handling in `configure.ac`Herbert Valerio Riedel2016-04-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...` scheme use the `CC=...` style scheme. The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to stage{1,2,3}, while having a separate _STAGE0 set of env-vars denote the bootstrap-toolchain flags/programs. This should be simpler, less confusing, and somewhat more in line with Autoconf's idioms (allowing us to reuse more of Autoconf rather than (re)inventing our own confusing non-standard m4 macros to do stuff that Autoconf could almost do already for us) Morever, expose CC_STAGE0 as a so-called "precious" variable. So now we can better control which bootstrapping gcc is used (by default the one used by the stage0 ghc, unless CC_STAGE0 is overriden) ``` Some influential environment variables: CC_STAGE0 C compiler command (bootstrap) CC C compiler command CFLAGS C compiler flags ... Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. ``` Test Plan: I've tested that cross-compiling with `--target=powerpc-linux-gnu` still works, and tried a few variants of settting `CC=` and `CC_STAGE0=`; `./validate` passed as well Reviewers: erikd, austin, bgamari, simonmar Reviewed By: simonmar Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2078
* Add NCG support for AIX/ppc32Herbert Valerio Riedel2016-03-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This extends the previous work to revive the unregisterised GHC build for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later) hardware, but the PPC32 instructions implemented in the PPC NCG represent a compatible subset of the POWER4 ISA. IBM AIX follows the PowerOpen ABI (and shares many similiarites with the Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF format (compared to ELF). This doesn't support dynamic libraries yet. A major limiting factor is that the AIX assembler does not support the `@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's assembler supports. Therefore we need to avoid emitting those. In case of numeric literals we simply compute the functions ourselves, while for labels we have to use local TOCs and hope everything fits into a 16bit offset (for ppc32 this gives us at most 16384 entries per TOC section, which is enough to compile GHC). Another issue is that XCOFF doesn't seem to have a relocation type for label-differences, and therefore the label-differences placed into tables-next-to-code can't be relocated, but the linker may rearrange different sections, so we need to place all read-only sections into the same `.text[PR]` section to workaround this. Finally, the PowerOpen ABI distinguishes between function-descriptors and actualy entry-point addresses. For AIX we need to be specific when emitting assembler code whether we want the address of the function descriptor `printf`) or for the entry-point (`.printf`). So we let the asm pretty-printer prefix a dot to all emitted subroutine calls (i.e. `BL`) on AIX only. For now, STG routines' entry-point labels are not prefixed by a label and don't have any associated function-descriptor. Reviewers: austin, trommler, erikd, bgamari Reviewed By: trommler, erikd, bgamari Differential Revision: https://phabricator.haskell.org/D2019
* Use stage1 build variables when building the RTSReid Barton2016-01-271-1/+1
| | | | | | | | | | | | | The fourth argument of distdir-way-opts was missing. So, for example, SRC_HC_OPTS_STAGE1 was not used when building the RTS. Test Plan: validate --slow Reviewers: austin, bgamari, thomie Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D1857
* Switch from -this-package-key to -this-unit-id.Edward Z. Yang2016-01-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A small cosmetic change, but we have to do a bit of work to actually support it: - Cabal submodule update, so that Cabal passes us -this-unit-id when we ask for it. This includes a Cabal renaming to be consistent with Unit ID, which makes ghc-pkg a bit more scrutable. - Build system is updated to use -this-unit-id rather than -this-package-key, to avoid deprecation warnings. Needs a version test so I resurrected the old test we had (sorry rwbarton!) - I've *undeprecated* -package-name, so that we are in the same state as GHC 7.10, since the "correct" flag will have only entered circulation in GHC 8.0. - I removed -package-key. Since we didn't deprecate -package-id I think this should not cause any problems for users; they can just change their code to use -package-id. - The package database is indexed by UNIT IDs, not component IDs. I updated the naming here. - I dropped the signatures field from ExposedModule; nothing was using it, and instantiatedWith from the package database field. - ghc-pkg was updated to use unit ID nomenclature, I removed the -package-key flags but I decided not to add any new flags for now. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: 23Skidoo, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1780
* rts: Kill PAPI supportBen Gamari2015-11-181-27/+0
| | | | | | | | | | | | | | | This hasn't been used for a very long time and will soon be superceded by perf_events support. Test Plan: validate Reviewers: austin, simonmar Reviewed By: austin, simonmar Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1493
* Implement function-sections for Haskell code, #8405Simon Brenner2015-11-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Allow the GHCi Linker to resolve related dependencies when loading DLLsTamar Christina2015-11-071-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Libdw: Add libdw-based stack unwindingBen Gamari2015-10-171-0/+8
| | | | | | | | | | | | | | | | | | | | | This adds basic support to the RTS for DWARF-assisted unwinding of the Haskell and C stack via libdw. This only adds the infrastructure; consumers of this functionality will be introduced in future diffs. Currently we are carrying the initial register collection code in Libdw.c but this will eventually make its way upstream to libdw. Test Plan: See future patches Reviewers: Tarrasch, scpmw, austin, simonmar Reviewed By: austin, simonmar Subscribers: simonmar, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1196 GHC Trac Issues: #10656
* Build system: simplify install.mk.inThomas Miedema2015-08-211-2/+2
| | | | | | | | | | This will allow fixing #1851 more easily ("make install-strip" should work). This reverts 57e2a81c589103b50da80a9e378b1a11285bd521: "On Cygwin, use a Cygwin-style path for /bin/install's destination" Update submodule haddock and hsc2hs.
* Implement PowerPC 64-bit native code backend for LinuxPeter Trommler2015-07-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Extend the PowerPC 32-bit native code generator for "64-bit PowerPC ELF Application Binary Interface Supplement 1.9" by Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification -- OpenPOWER ABI for Linux Supplement" by IBM. The latter ABI is mainly used on POWER7/7+ and POWER8 Linux systems running in little-endian mode. The code generator supports both static and dynamic linking. PowerPC 64-bit code for ELF ABI 1.9 and 2 is mostly position independent anyway, and thus so is all the code emitted by the code generator. In other words, -fPIC does not make a difference. rts/stg/SMP.h support is implemented. Following the spirit of the introductory comment in PPC/CodeGen.hs, the rest of the code is a straightforward extension of the 32-bit implementation. Limitations: * Code is generated only in the medium code model, which is also gcc's default * Local symbols are not accessed directly, which seems to also be the case for 32-bit * LLVM does not work, but this does not work on 32-bit either * Must use the system runtime linker in GHCi, because the GHC linker for "static" object files (rts/Linker.c) for PPC 64-bit is not implemented. The system runtime (dynamic) linker works. * The handling of the system stack (register 1) is not ELF- compliant so stack traces break. Instead of allocating a new stack frame, spill code should use the "official" spill area in the current stack frame and deallocation code should restore the back chain * DWARF support is missing Fixes #9863 Test Plan: validate (on powerpc, too) Reviewers: simonmar, trofi, erikd, austin Reviewed By: trofi Subscribers: bgamari, arnons1, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D629 GHC Trac Issues: #9863
* Rename $1_$2_$3_LIB_NAME to LIB_FILE.Edward Z. Yang2015-06-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we introduced user-friendly library names (e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to be written out by ghc-cabal, $1_$2_LIB_NAME. What I didn't realize at the time was that this conflicts with an existing variable in the build system, $1_$2_$3_LIB_NAME, which (confusingly) refers to something like 'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'. This is pretty confusing (despite never conflicting), so I renamed this variable to LIB_FILE for enhanced greppability. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1002
* Typos in error messages and in commentsGabor Greif2015-04-101-1/+1
|
* Replaced SEH handles with VEH handlers which should work uniformly across ↵Tamar Christina2015-03-031-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | x86 and x64 Summary: On Windows, the default action for things like division by zero and segfaults is to pop up a Dr. Watson error reporting dialog if the exception is unhandled by the user code. This is a pain when we are SSHed into a Windows machine, or when we want to debug a problem with gdb (gdb will get a first and second chance to handle the exception, but if it doesn't the pop-up will show). veh_excn provides two macros, `BEGIN_CATCH` and `END_CATCH`, which will catch such exceptions in the entire process and die by printing a message and calling `stg_exit(1)`. Previously this code was handled using SEH (Structured Exception Handlers) however each compiler and platform have different ways of dealing with SEH. `MSVC` compilers have the keywords `__try`, `__catch` and `__except` to have the compiler generate the appropriate SEH handler code for you. `MinGW` compilers have no such keywords and require you to manually set the SEH Handlers, however because SEH is implemented differently in x86 and x64 the methods to use them in GCC differs. `x86`: SEH is based on the stack, the SEH handlers are available at `FS[0]`. On startup one would only need to add a new handler there. This has a number of issues such as hard to share handlers and it can be exploited. `x64`: In order to fix the issues with the way SEH worked in x86, on x64 SEH handlers are statically compiled and added to the .pdata section by the compiler. Instead of being thread global they can now be Image global since you have to specify the `RVA` of the region of code that the handlers govern. You can on x64 Dynamically allocate SEH handlers, but it seems that (based on experimentation and it's very under-documented) that the dynamic calls cannot override static SEH handlers in the .pdata section. Because of this and because GHC no longer needs to support < windows XP, the better alternative for handling errors would be using the in XP introduced VEH. The bonus is because VEH (Vectored Exception Handler) are a runtime construct the API is the same for both x86 and x64 (note that the Context object does contain CPU specific structures) and the calls are the same cross compilers. Which means this file can be simplified quite a bit. Using VEH also means we don't have to worry about the dynamic code generated by GHCi. Test Plan: Prior to this diff the tests for `derefnull` and `divbyzero` seem to have been disabled for windows. To reproduce the issue on x64: 1) open ghci 2) import GHC.Base 3) run: 1 `divInt` 0 which should lead to ghci crashing an a watson error box displaying. After applying the patch, run: make TEST="derefnull divbyzero" on both x64 and x86 builds of ghc to verify fix. Reviewers: simonmar, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D691 GHC Trac Issues: #6079
* Package keys (for linking/type equality) separated from package IDs.Edward Z. Yang2014-08-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch set makes us no longer assume that a package key is a human readable string, leaving Cabal free to "do whatever it wants" to allocate keys; we'll look up the PackageId in the database to display to the user. This also means we have a new level of qualifier decisions to make at the package level, and rewriting some Safe Haskell error reporting code to DTRT. Additionally, we adjust the build system to use a new ghc-cabal output Make variable PACKAGE_KEY to determine library names and other things, rather than concatenating PACKAGE/VERSION as before. Adds a new `-this-package-key` flag to subsume the old, erroneously named `-package-name` flag, and `-package-key` to select packages by package key. RFC: The md5 hashes are pretty tough on the eye, as far as the file system is concerned :( ToDo: safePkg01 test had its output updated, but the fix is not really right: the rest of the dependencies are truncated due to the fact the we're only grepping a single line, but ghc-pkg is wrapping its output. ToDo: In a later commit, update all submodules to stop using -package-name and use -this-package-key. For now, we don't do it to avoid submodule explosion. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D80
* Include LD_OPTS when building the RTS shared libsSimon Marlow2014-04-071-1/+4
|
* Fix inplace dynamic linking on OS X (#8266)Christiaan Baaj2014-01-281-2/+4
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Fix specification of -z origin for gold.Austin Seipp2014-01-071-1/+1
| | | | | | | Gold apparently doesn't recognize `-z origin`, only `-zorigin` it seems. Authored-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Correctly set relative rpath for OS X (#8266)Austin Seipp2013-10-251-1/+4
| | | | | | | | | This includes both executables (by correcly setting the rpath to the topDir) and libffi, and GHC itself, so that everything works with no build tree. Authored-by: Christiaan Baaj <christiaan.baaij@gmail.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Use dynamic linking only if the GHC package is compiled with -dynamic (#8376)Simon Marlow2013-10-111-0/+1
|
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-3/+3
|
* Remove DYNAMIC_GHC_PROGRAMS tests in the linkerSimon Marlow2013-08-221-4/+0
| | | | | The linker is usable even when GHCi is dynamically linked. These tests make the linker_unload test fail.
* Fix dynlib paths in the RTS too; part of #7833Ian Lynagh2013-06-221-0/+1
|
* Don't use -finline-limit with Clang.Austin Seipp2013-06-211-0/+2
| | | | | | It's unsupported. Signed-off-by: Austin Seipp <aseipp@pobox.com>
* Cleaning fixes, and other build system tweaks; part of #7941Ian Lynagh2013-06-141-6/+6
|
* Make sure the RTS is built, even when no programs are being built with stage1Ian Lynagh2013-05-101-1/+1
| | | | Part of #7841
View Lorry Controller Status