[commit: ghc] wip/ghc-8.6-ci: Revert "Windows: Use the "big" PE object format on amd64" (c682701)
git at git.haskell.org
git at git.haskell.org
Thu Dec 27 17:00:15 UTC 2018
Repository : ssh://git@git.haskell.org/ghc
On branch : wip/ghc-8.6-ci
Link : http://ghc.haskell.org/trac/ghc/changeset/c68270119b7f215a6d7f30fc020856fa94056dc3/ghc
>---------------------------------------------------------------
commit c68270119b7f215a6d7f30fc020856fa94056dc3
Author: Ben Gamari <ben at smart-cactus.org>
Date: Sun Dec 23 20:09:30 2018 -0500
Revert "Windows: Use the "big" PE object format on amd64"
This ended up breaking GHCi due to alignment issues. See #16071.
This reverts commit ed86e3b531322f74d2c2d00d7ff8662b08fabde6.
>---------------------------------------------------------------
c68270119b7f215a6d7f30fc020856fa94056dc3
compiler/main/DriverPipeline.hs | 38 +-------------------------------------
1 file changed, 1 insertion(+), 37 deletions(-)
diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs
index 6d2e5b7..92e3455 100644
--- a/compiler/main/DriverPipeline.hs
+++ b/compiler/main/DriverPipeline.hs
@@ -1337,11 +1337,6 @@ runPhase (RealPhase (As with_cpp)) input_fn dflags
(local_includes ++ global_includes
-- See Note [-fPIC for assembler]
++ map SysTools.Option pic_c_flags
- -- See Note [Produce big objects on Windows]
- ++ [ SysTools.Option "-Wa,-mbig-obj"
- | platformOS (targetPlatform dflags) == OSMinGW32
- , not $ target32Bit (targetPlatform dflags)
- ]
-- We only support SparcV9 and better because V8 lacks an atomic CAS
-- instruction so we have to make sure that the assembler accepts the
@@ -2154,32 +2149,6 @@ generateMacros prefix name version =
-- ---------------------------------------------------------------------------
-- join object files into a single relocatable object file, using ld -r
-{-
-Note [Produce big objects on Windows]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The Windows Portable Executable object format has a limit of 32k sections, which
-we tend to blow through pretty easily. Thankfully, there is a "big object"
-extension, which raises this limit to 2^32. However, it must be explicitly
-enabled in the toolchain:
-
- * the assembler accepts the -mbig-obj flag, which causes it to produce a
- bigobj-enabled COFF object.
-
- * the linker accepts the --oformat pe-bigobj-x86-64 flag. Despite what the name
- suggests, this tells the linker to produce a bigobj-enabled COFF object, no a
- PE executable.
-
-We must enable bigobj output in a few places:
-
- * When merging object files (DriverPipeline.joinObjectFiles)
-
- * When assembling (DriverPipeline.runPhase (RealPhase As ...))
-
-Unfortunately the big object format is not supported on 32-bit targets so
-none of this can be used in that case.
--}
-
joinObjectFiles :: DynFlags -> [FilePath] -> FilePath -> IO ()
joinObjectFiles dflags o_files output_fn = do
let mySettings = settings dflags
@@ -2189,7 +2158,7 @@ joinObjectFiles dflags o_files output_fn = do
SysTools.Option "-nostdlib",
SysTools.Option "-Wl,-r"
]
- -- See Note [No PIE while linking] in DynFlags
+ -- See Note [No PIE while linking] in SysTools
++ (if sGccSupportsNoPie mySettings
then [SysTools.Option "-no-pie"]
else [])
@@ -2208,11 +2177,6 @@ joinObjectFiles dflags o_files output_fn = do
&& ldIsGnuLd
then [SysTools.Option "-Wl,-no-relax"]
else [])
- -- See Note [Produce big objects on Windows]
- ++ [ SysTools.Option "-Wl,--oformat,pe-bigobj-x86-64"
- | OSMinGW32 == osInfo
- , not $ target32Bit (targetPlatform dflags)
- ]
++ map SysTools.Option ld_build_id
++ [ SysTools.Option "-o",
SysTools.FileOption "" output_fn ]
More information about the ghc-commits
mailing list