Skip to content

Draft: Windows ASLR support

Ben Gamari requested to merge wip/windows-clang into master

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 and lld 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).
Edited by Ben Gamari

Merge request reports