summaryrefslogtreecommitdiff
path: root/driver/utils
Commit message (Collapse)AuthorAgeFilesLines
* Lowercase windows importsMoritz Angermann2019-05-271-2/+2
| | | | | | | | | | While windows and macOS are currently on case-insensitive file systems, this poses no issue on those. When cross compiling from linux with a case sensitive file system and mingw providing only lowercase headers, this in fact produces an issue. As such we just lowercase the import headers, which should still work fine on a case insensitive file system and also enable mingw's headers to be usable porperly.
* driver/utils/dynwrapper.c: Remove unused variableSimon Jakobi2018-02-251-1/+0
| | | | | | | | | | | | | | | The variable was already unused when the file was introduced in b35a6ce0e34255d200ddcf341ffc645fd237ea32. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11777 Differential Revision: https://phabricator.haskell.org/D4426
* Release console for ghci wrapperTamar Christina2017-09-262-3/+12
| | | | | | | | | | | | | | | | | | | | | | Summary: It seems the call that caused issues with the gcc wrapper before was needed for the ghci wrapper in order for the child process to be the one handling console events. This code slightly refactors the wrappers to make sure only ghci calls FreeConsole and nothing else. Test Plan: ./validate , open ghci.exe press ctrl+c Reviewers: RyanGlScott, austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #14150 Differential Revision: https://phabricator.haskell.org/D4028
* Implement split-sections support for windows.Tamar Christina2017-07-081-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Initial implementation of split-section on Windows. This also corrects section namings and uses the platform convention of `$` instead of `.` to separate sections. Implementation is based on @awson's patches to binutils. Binutils requires some extra help when compiling the libraries for GHCi usage. We drop the `-T` and use implicit scripts to amend the linker scripts instead of replacing it. Because of these very large GHCi object files, we need big-obj support, which will be added by another patch. Test Plan: ./validate Reviewers: awson, austin, bgamari Subscribers: dfeuer, rwbarton, thomie, snowleopard, #ghc_windows_task_force GHC Trac Issues: #12913 Differential Revision: https://phabricator.haskell.org/D3383
* Fix slash escaping in cwrapper.cTamar Christina2017-06-081-1/+1
| | | | | | | | | | | | | | | | Summary: Escape `\` in paths on Windows in `cwapper.c` when we re-output the paths. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13666 Differential Revision: https://phabricator.haskell.org/D3628
* cpp: Use #pragma once instead of #ifndef guardsBen Gamari2017-04-231-4/+1
| | | | | | | | | | | | | | This both says what we mean and silences a bunch of spurious CPP linting warnings. This pragma is supported by all CPP implementations which we support. Reviewers: austin, erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3482
* Fix Windows GCC driverTamar Christina2017-03-141-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Windows 10 Insiders build 15019+ which will probably be released mainstream somewhere this year Microsoft seems to have started being stricter with API calls. The call to `FreeConsole` just after `CreateProcess` is making Windows treat the process as an interactive process. In which case it tries to use the `Desktop session` but fails resulting in the cryptic error reported. I don't understand why the call to `FreeConsole` was there and it doesn't seem to be needed, so removed. This fixes #13411 Test Plan: ./validate, alternative just do anything with ghc which requires compilation. Reviewers: austin, bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3319
* Properly detect MinTTY when running GHCi on WindowsRyan Scott2017-01-102-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | Before, we detecting the presence of MinTTY on Windows in a very imprecise way: by checking if the `_` environment variable was set. Not only is this easy to circumvent, but it also yields false positives on terminals like ConEmu. This changes the test to use the `GetFileInformationByHandleEx` function instead, which provides a far more accurate check for MinTTY's presence. I've tested this on PowerShell, MSYS2, Cygwin, ConEmu, and Git Bash, and it does the right thing on each one. Fixes #12958. Test Plan: Run GHCi on many different Windows and MinTTY consoles Reviewers: erikd, Phyx, austin, bgamari Reviewed By: Phyx, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2878 GHC Trac Issues: #12958
* Implement function-sections for Haskell code, #8405Simon Brenner2015-11-121-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Rename _closure to _static_closure, apply naming consistently."Edward Z. Yang2014-10-201-1/+1
| | | | | | | This reverts commit 35672072b4091d6f0031417bc160c568f22d0469. Conflicts: compiler/main/DriverPipeline.hs
* Rename _closure to _static_closure, apply naming consistently.Edward Z. Yang2014-10-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In preparation for indirecting all references to closures, we rename _closure to _static_closure to ensure any old code will get an undefined symbol error. In order to reference a closure foobar_closure (which is now undefined), you should instead use STATIC_CLOSURE(foobar). For convenience, a number of these old identifiers are macro'd. Across C-- and C (Windows and otherwise), there were differing conventions on whether or not foobar_closure or &foobar_closure was the address of the closure. Now, all foobar_closure references are addresses, and no & is necessary. CHARLIKE/INTLIKE were not changed, simply alpha-renamed. Part of remove HEAP_ALLOCED patch set (#8199) Depends on D265 Signed-off-by: Edward Z. Yang <ezyang@mit.edu> Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D267 GHC Trac Issues: #8199
* Make dynamic GHC no Windows installable tooIan Lynagh2013-05-161-3/+1
| | | | | We need different paths in the wrapper, as teh installed tree is a different shape to the build tree.
* Define the right RTS config in the Windows dyn wrapper programsIan Lynagh2013-05-141-3/+5
| | | | | | This is particularly important as without it validate fails, as it tries to pass RTS options to haddock, and with the default RTS config those options aren't permitted.
* More work towards dynamic programs on WindowsIan Lynagh2013-05-121-0/+197
| | | | | | | | | | | | | | | | | | | Dynamic GHC is now working in-place, but pathologically slow due to the DLL split. (GHC assumes that all intra-package calls are in the same DLL, but that isn't true when we split the GHC package into 2 DLLs. That means that GHC's startup time is around 22 seconds, as it is doing run-time linking). Also, ghci isn't actually working yet: $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.7.20130512: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... <command line>: can't load .so/.DLL for: HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL) ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be found.
* Fix a tiny bug in cwrapper.cIan Lynagh2012-03-161-3/+3
| | | | Caught by -Werror
* use Win32 CreateProcess() rather than mingw spawnv() (#4531)Simon Marlow2011-01-061-37/+94
|
* Fix build on WindowsIan Lynagh2010-02-192-3/+2
|
* Refactor gcc.c, pulling out the reusable codeIan Lynagh2010-02-182-0/+105
|
* Wrap gcc on Windows, to provide the -B flagsIan Lynagh2009-10-272-0/+44