summaryrefslogtreecommitdiff
path: root/rts/ghc.mk
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Generate dependencies for .cmm files properlyIan Lynagh2013-05-091-3/+6
|
* Fix the name of libffiIan Lynagh2013-05-091-12/+13
| | | | | On Windows, we need to keep the DLL called libffi-6.dll (rather than libffi.dll) or Windows can't find it.
* Fix build on OS XIan Lynagh2013-04-301-2/+4
| | | | sed on OS X doesn't handle \+
* Fix buildIan Lynagh2013-04-281-2/+2
|
* Add -L flags to libs.depend (fixes #7465)Ian Lynagh2013-04-281-1/+3
| | | | Based on a patch from Peter Trommler
* Tidy up some build system codeIan Lynagh2013-04-281-2/+2
|
* When linking with $ORIGIN rpaths, use the "-z origin" linker flag tooIan Lynagh2013-04-271-1/+1
| | | | | On FreeBSD, one needs use "-z origin" in order to enable resolution of $ORIGIN in RPATH. Part of #7819.
* Follow build system changes in integer-gmpIan Lynagh2013-04-201-1/+1
| | | | Also a couple of other fixes and sanity checks along the way.
* Rename the FFI DLL to libffi.dll for consistencyIan Lynagh2013-04-061-5/+7
|
* Fix installationIan Lynagh2013-04-031-3/+2
| | | | | | The build system thought that the RTS built more library files than it actually did, and installation failed when we tried to 'strip' one of these non-existant files.
* Fix the names of the libffi archivesIan Lynagh2013-03-241-1/+1
| | | | Fixes a bug which meant that they weren't getting installed.
* Change how we handle libffiIan Lynagh2013-03-231-17/+22
| | | | | | | | | | | I think overall the new approach is simpler. Rather than unpacking the libffi.a and putting the .o files into our libHSrts.a, we just use the libffi.a. This change also means that when compiling programs for the dyn way, they get explicitly linked against libffi.so (rather than relying on librts.so being linked against it). This might fix a problem on FreeBSD, where programs cannot find libffi.so.
* Remove some more old, unused codeIan Lynagh2013-03-211-6/+2
|
* Fix build with non-Linux ELF OSesIan Lynagh2013-03-201-1/+1
| | | | | | | We were only setting an RPATH for the RTS DLL on Linux, but as far as I can see we should be doing it for all ELF OSes. Hopefully this will fix the problem where the installed ghc-pkg can't find libffi.dll on FreeBSD.
* By default, use the dynamic way for programs in the GHC treeIan Lynagh2013-03-151-2/+2
| | | | | In particular, this means that GHCi will use DLLs, rather than loading object files itself.
* Use more of the automatically generated INPLACE variablesIan Lynagh2013-03-031-2/+2
|
* Define $(prog)_INPLACE variables automatically, and start using themIan Lynagh2013-03-031-2/+2
|
* Build fixes following build system refactoringIan Lynagh2013-02-211-0/+2
|
* Remove the MACOSX_DEPLOYMENT stuff; fixes #7559Ian Lynagh2013-02-171-5/+0
| | | | | If anyone wants to do this in the future, they should just set appropriate CC_OPTS/LD_OPTS variables instead.
* Finish removing BootingFromHcIan Lynagh2013-02-171-4/+0
|
* Fixes to the rts C flags for the debug waySimon Marlow2013-02-141-1/+1
| | | | | An earlier attempt at cleaning things up had made the debug way compile with optimisation due to flag ordering issues.
* use GhcRtsHcOpts and GhcRtsCcOpts for the debug way tooSimon Marlow2013-01-291-5/+5
|
* Add a -rpath entry for the RTS library, so that it can find libffiIan Lynagh2013-01-041-0/+4
| | | | | | | | | | This fixes dynamic library resolution when --enable-new-dtags is used (#7062). When --enable-new-dtags is used when linking an executable, a RUNPATH as well as RPATH is set. The linker then ignores RPATH, and RUNPATH is only used for directly (not transitively) needed libraries. As the program doesn't directly need libffi, it isn't found.
* Link in-tree libffi to rts. Fixes trac #5743.Peter Trommler2012-11-301-0/+6
|
* libffi build system tweaksIan Lynagh2012-11-301-1/+4
|
View Lorry Controller Status