| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, giving `-optl` linker flags to `ghc` on the command line placed
them in the wrong place in the `ld` command line:
They were given before all the Haskell libararies, when they should appear after.
Background:
Most linkers like `ld.bfd` and `ld.gold`, but not the newer LLVM `lld`, work in
a way where the order of `-l` flags given matters; earlier `-lmylib1` flags are
supposed to create "holes" for linker symbols that are to be filled with later
`lmylib2` flags that "fill the holes" for these symbols.
As discovered in
https://github.com/haskell/cabal/pull/5451#issuecomment-518001240,
the `-optl` flags appeared before e.g. the
-lHStext-1.2.3.1
-lHSbinary-0.8.6.0
-lHScontainers-0.6.0.1
flags that GHC added at the very end.
Haskell libraries typically depend on C libraries, so `-lHS*` flags will create
holes for the C libraries to fill in, but that only works when those libraries'
`-l` flags are given **after** the `-lHS*` flags; until now they were given
before, which was wrong.
This meant that Cabal's `--ld-options` flag and `ld-options` `.cabal` file field
were pretty ineffective, unless you used the `--ld-option=--start-group` hack as
(https://github.com/haskell/cabal/pull/5451#issuecomment-406761676) that
convinces the classical linkers to not be dependent on the order of linker flags
given.
This commit fixes the problem by simply flipping the order, putting `-optl`
flags at the end, after Haskell libraries.
The code change is effectively only `args1 ++ args` -> `args ++ args1`
but the commit also renames the variables for improved clarity.
Simple way to test it:
ghc --make Main.hs -fforce-recomp -v -optl-s
on a `Main.hs` like:
import qualified Data.Set as Set
main = print $ Set.fromList "hello"
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two problems with LLVM version checking:
- The parser would only parse x and x.y formatted versions. E.g. 1.2.3
would be rejected.
- The version check was too strict and would reject x.y formatted
versions. E.g. when we support version 7 it'd reject 7.0 ("LLVM
version 7.0") and only accept 7 ("LLVM version 7").
We now parse versions with arbitrarily deep minor numbering (x.y.z.t...)
and accept versions as long as the major version matches the supported
version (e.g. 7.1, 7.1.2, 7.1.2.3 ...).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch was motivated by some performance characterization work done
for #16822, where we suspected that GHC was spending a lot of time waiting
on the linker to be done. (That turned out to be true.)
The tracing is taken care of by ErrUtils.withTiming, so this patch just defines
and uses a little wrapper around that function in all the helpers for
calling the various systools (C compiler, linker, unlit, ...).
With this patch, assuming a GHC executable linked against an eventlog-capable
RTS (RTS ways that contain the debug, profiling or eventlog way units), we can
measure how much time is spent in each of the SysTools when building hello.hs
by simply doing:
ghc hello.hs -ddump-timings +RTS -l
The event names are "systool:{cc, linker, as, unlit, ...}".
|
| |
|
|
|
|
|
| |
LLVM version numberinf changed recently. Previously, releases were numbered
4.0, 5.0 and 6.0 but with version 7, they dropped the redundant ".0".
Fix requires for Llvm detection and some code.
|
| |
|
|
|
|
|
| |
ghc-pkg needs to be aware of platforms so it can figure out which
subdire within the user package db to use. This is admittedly
roundabout, but maybe Cabal could use the same notion of a platform as
GHC to good affect too.
|
| |
|
|
|
|
|
| |
Previously we would pass flags intended for the C compiler to the C++
compiler (see #16738). This would cause, for instance, `-std=gnu99` to
be passed to the C++ compiler, causing spurious test failures. Fix this
by maintaining a separate set of flags for C++ compilation invocations.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The splitter is an evil Perl script that processes assembler code.
Its job can be done better by the linker's --gc-sections flag. GHC
passes this flag to the linker whenever -split-sections is passed on
the command line.
This is based on @DemiMarie's D2768.
Fixes Trac #11315
Fixes Trac #9832
Fixes Trac #8964
Fixes Trac #8685
Fixes Trac #8629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: make test TEST=T14452
Reviewers: hvr, bgamari, monoidal, thomie, osa1
Reviewed By: osa1
Subscribers: rwbarton, carter
GHC Trac Issues: #14452
Differential Revision: https://phabricator.haskell.org/D5318
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM, like GHC, processes flags in the order that they appear.
Consequently, we need to ensure the user-provided flags appear last so
they can override flags produced by GHC. See #14821.
Test Plan: `ghc -O2 -optlo-O2 -v3 $FILE` and ensure that `opt` and `llc`
are invoked with `-O2`.
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #14821
Differential Revision: https://phabricator.haskell.org/D4421
|
|
|
Summary:
SysTools and DriverTools have an annoying mutual dependency.
They also each contain pieces of the linker. In order for
changes to be shared between the library and the exe linking
code this dependency needs to be broken in order to avoid
using hs-boot files.
Reviewers: austin, bgamari, erikd
Reviewed By: bgamari
Subscribers: rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D4071
|
