Draft: Windows ASLR support
Recently msys2 started enabling ASLR support in its toolchain, uncovering a number of bugs in GHC's code generation strategy on Windows as well as bugs in upstream toolchain components (e.g. ld.bfd
, see binutils #26757). This has rendered GHC completely unusable with recent msys2 toolchains (see #16780 (closed)).
Since the binutils issues prevent us from using ld.bfd
, I took this opportunity to try moving GHC to use lld
for linking, as suggested in #16084 (closed). Unfortunately, due to an unrelated binutils
bug (see #9907 (closed)) gas
currently produces (ill-formed) objects that lld
does not understand. Sadly this means that we also cannot use gcc
. For this reason, this branch moves GHC's Windows toolchain entirely to LLVM: Clang for C compilation and lld
for linking.
Along with moving to clang
, I fix a variety of latent code generation bugs where code produced by GHC would assume that it resided in low memory.
Doing this required some a somewhat orthogonal preparatory steps:
- Remove a use of the GNU nested functions extension in
rts/linker/PEi386.c
- Fix the handling of overflowing relocations for data symbols (see #20978 (closed))
Thanks to @Phyx for his wisdom and guidance around the Windows toolchain ecosystem.
To do
-
Clean up hacky toolchain integration -
Add clang
andlld
packages to win32-tarballs> -
Make code generation changes conditional -
Sort out runtime linker issues -
Propagate symbol type changes to MachO and ELF linkers -
Fix HeapAlloc
usage to minimize relocation overflow (#20979 (closed)) -
Investigate non-existence of the __image_base
symbol; rather use__ImageBase
-
Don't generate jump islands for TNTC symbols (#20983).