| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
| | | |
| | | |
| | | | |
Fixes missing TEST_CC_OPTS in testsuite tests.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Disable support for library-for-ghci on Windows as described
in #21068.
- Teach Cabal to use `ar -L` when available
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously we would report framework failures of tests marked as fragile
as failures. Now we rather treat them as fragile test failures, which
are not fatal to the testsuite run. Noticed while investigating #21293.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Currently llvm-ar does not handle long file paths, resulting in
occassional failures of these tests and #21293.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Otherwise the linker will export all symbols, including those provided
by the RTS, from the produced shared object. Consequently, attempting
to link against multiple objects simultaneously will cause the linker
to complain that RTS symbols are multiply defined. Avoid this
by limiting the DLL exports with a module definition file.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
I'm a bit unclear on how this previously worked as it attempted
to build an executable without defining `main`.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Split up the C and C++ uses since the latter is significantly more
platform-dependent.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously we used libgcc_s's import library in T13606. However, now that
we ship with clang we no longer have this library. Instead we now use gdi32.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The new toolchain has fixed it.
Closes #15670.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I have not seen it fail since moving to clang.
Closes #12714.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously this test was C++ which made it a bit of a portability
problem.
|
| | | |
| | | |
| | | |
| | | | |
This flag is not applicable when Clang is used.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Bump win32-tarballs to 0.7
* Move Windows toolchain autoconf logic into separate file
* Use clang and LLVM utilities as described in #21019
* Disable object merging as lld doesn't support -r
* Drop --oformat=pe-bigobj-x86-64 arguments from ld flags as LLD detects
that the output is large on its own.
* Drop gcc wrapper since Clang finds its root fine on its own.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Drop hack for #1828, among others as they appear to be unnecessary when
using `llvm-windres`.
|
| | |/
| | |
| | |
| | | |
This is a gcc-specific extension.
|
| | |
| | |
| | |
| | |
| | | |
Previously `isArchive` could leak a `FILE` handle if the `fread`
returned a short read.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously the RTS linker would call initializers during the
"resolve" phase of linking. However, this is problematic in the
case of cyclic dependencies between objects. In particular, consider
the case where we have a situation where a static library
contains a set of recursive objects:
* object A has depends upon symbols in object B
* object B has an initializer that depends upon object A
* we try to load object A
The linker would previously:
1. start resolving object A
2. encounter the reference to object B, loading it resolve object B
3. run object B's initializer
4. the initializer will attempt to call into object A,
which hasn't been fully resolved (and therefore protected)
Fix this by moving constructor execution to a new linking
phase, which follows resolution.
Fix #21253.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
swprintf deviates from usual `snprintf` semantics in that it does not
guarantee reasonable behavior when the buffer is NULL (that is,
returning the number of bytes that would have been emitted).
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
We now preserve the address that we last mapped, allowing us to resume
our search and avoiding quadratic allocation costs. This fixes the
runtime of T10296a, which allocates many adjustors.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a significant rework of the PEi386 linker, making the linker
compatible with high image base addresses. Specifically, we now use the
m32 allocator instead of `HeapAllocate`.
In addition I found a number of latent bugs in our handling of import
libraries and relocations. I've added quite a few comments describing
what I've learned about Windows import libraries while fixing these.
Thanks to Tamar Christina (@Phyx) for providing the address space search
logic, countless hours of help while debugging, and his boundless
Windows knowledge.
Co-Authored-By: Tamar Christina <tamar@zhox.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Tables-next-to-code mandates that we treat symbols with info tables like
data since we cannot relocate them using a jump island.
See #20983.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes handling of overflowed relocations on PEi386 targets:
* Refuse to create jump islands for relocations of data symbols
* Correctly handle the `__imp___acrt_iob_func` symbol, which is an new
type of symbol: `SYM_TYPE_INDIRECT_DATA`
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As noted in #20978, the linker would previously handle overflowed
relocations by creating a jump island. While this is fine in the case of
code symbols, it's very much not okay in the case of data symbols. To
fix this we must keep track of whether each symbol is code or data and
relocate them appropriately. This patch takes the first step in this
direction, adding a symbol type field to the linker's symbol table. It
doesn't yet change relocation behavior to take advantage of this
knowledge.
Fixes #20978.
|
| | |
| | |
| | |
| | |
| | | |
Previously we would leak the section information of the `.bss`
section.
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
| |
On Windows with high-entropy ASLR we must use %rip-relative addressing
to avoid overflowing the signed 32-bit immediate size of x86-64.
Since %rip-relative addressing comes essentially for free and can make
linking significantly easier, we use it on all platforms.
|
|
|
|
|
| |
The matching on GhcPass introduced by 95275a5f25a is not necessary.
This patch reverts it to make the code simpler.
|
|
|
|
| |
Addresses #21295.
|
|
|
|
|
|
| |
This is necessary to build recent `text` commits.
Bumps Hackage index state for a hashable which builds with GHC 9.2.
|
|
|
|
|
| |
-Wuni-incomplete-patterns and apparent improvements in the pattern match
checker surfaced these.
|
|
|
|
| |
This makes it a bit easier to bump them.
|
| |
|
|
|
|
|
| |
Previously the `ipe` and `omit_pragmas` transformers were hackily
defined using the textual key-value syntax. Fix this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In !7511 (closed) I introduced a new allocator for adjustors,
AdjustorPool, which eliminates the address space fragmentation issues
which adjustors can introduce. In that work I focused on amd64 since
that was the platform where I observed issues.
However, in #21132 we noted that the size of adjustors is also a cause
of CI fragility on i386. In this MR I port i386 to use AdjustorPool.
Sadly the complexity of the i386 adjustor code does cause require a bit
of generalization which makes the code a bit more opaque but such is the
world.
Closes #21132.
|
|
|
|
| |
Unfortunately the i386 adjustor logic needs this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#20385)
Once we are done parsing the header of a module to obtain the options, we
look through the rest of the tokens in order to determine if they contain any
misplaced file header pragmas that would usually be ignored, potentially
resulting in bad error messages.
The warnings are reported immediately so that later errors don't shadow
over potentially helpful warnings.
Metric Increase:
T13719
|
|
|
|
| |
Since there may be .o files which are in fact archives.
|
|
|
|
| |
See #21068.
|
|
|
|
|
|
|
|
| |
Since object files may in fact be archive files, we must ensure that
their contents are merged rather than constructing an
archive-of-an-archive.
See #21068.
|