Daneel Yaitskov authored 4 years ago and Marge Bot committed 4 months ago

Check the RTS flag before doing any work with the given lazy string.

Fix #17949

Co-authored-by: Michael Peyton Jones <me@michaelpj.com>
Co-authored-by: Sylvain Henry <sylvain@haskus.fr>
Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>

Matthew Craven authored 11 months ago and Cheng Shao committed 4 months ago

This reverts commit 38c3afb6.

Matthew Craven authored 11 months ago and Cheng Shao committed 4 months ago

Fixes #23117. Fixes #23281. Fixes #23490.

This required:
 * Updating the bit-rotted compiler/Setup.hs and its setup-depends
 * Listing a few recently-added libraries and utilities
   in cabal.project-reinstall
 * Setting allow-boot-library-installs to 'True' since Cabal
   now considers the 'ghc' package itself a boot library for
   the purposes of this flag

Additionally, the allow-newer block in cabal.project-reinstall
was removed.  This block was probably added because when the
libraries/Cabal submodule is too new relative to the cabal-install
executable, solving the setup-depends for any package with a custom
setup requires building an old Cabal (from Hackage) against the
in-tree version of base, and this can fail un-necessarily due to
tight version bounds on base.  However, the blind allow-newer can
also cause the solver to go berserk and choose a stupid build plan
that has no business succeeding, and the failures when this happens
are dreadfully confusing. (See #23281 and #24363.)

Why does setup-depends solving insist on an old version of Cabal? See:
  https://github.com/haskell/cabal/blob/0a0b33983b0f022b9697f7df3a69358ee9061a89/cabal-install/src/Distribution/Client/ProjectPlanning.hs#L1393-L1410

The right solution here is probably to use the in-tree cabal-install
from libraries/Cabal/cabal-install with the build-cabal target rather
than whatever the environment happens to provide.  But this is left
for future work.

Matthew Craven authored 11 months ago and Cheng Shao committed 4 months ago

The svg image files mentioned in transformers.cabal were
previously not checked in, which broke sdist generation.

Cheng Shao authored 4 months ago and Marge Bot committed 4 months ago

This patch fixes an unnoticed undefined behavior in the bytecode
interpreter. It can be caught by building `rts/Interpreter.c` with
`-fsanitize=pointer-overflow`, the warning message is something like:

```
rts/Interpreter.c:1369:13: runtime error: addition of unsigned offset to 0x004200197660 overflowed to 0x004200197658
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior rts/Interpreter.c:1369:13
rts/Interpreter.c:1265:13: runtime error: addition of unsigned offset to 0x004200197660 overflowed to 0x004200197658
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior rts/Interpreter.c:1265:13
rts/Interpreter.c:1645:13: runtime error: addition of unsigned offset to 0x0042000b22f8 overflowed to 0x0042000b22f0
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior rts/Interpreter.c:1645:13
```

Whenever we do something like `SpW(-1)`, the negative argument is
implicitly converted to an unsigned integer type and causes pointer
arithmetic overflow. It happens to be harmless for most targets since
overflowing would wrap the result to desired value, but it's still
coincidental and undefined behavior. Furthermore, it causes real
damage to the wasm backend, given clang-20 will emit invalid wasm code
that crashes at run-time for this kind of C code! (see
https://github.com/llvm/llvm-project/issues/108770)

The fix here is adding some explicit casts to ensure we always use the
signed `ptrdiff_t` type as right hand operand of pointer arithmetic.

Cheng Shao authored 4 months ago and Marge Bot committed 4 months ago

This reverts commit 1c064ef1. Turns
out the GHC-WPC project does use it to observe Cmm in the pipeline,
see #25363.

This commit flips on support for shared libs, TH & ghci for wasm in
the testsuite, given support has been landed in previous commits.

This commit flips on the support for shared libs and ghci for the wasm
target, given all required support logic has been added in previous
commits.

This commit adds support for generating PIC to the wasm backend NCG.

This commit adds wasm backend iserv logic to the driver, see added
comments for explanation.

This commit fixes getGccSearchDirectory logic for wasm target, ensures
the correct search directory containing libc.so etc can be found by
GHC. getGccSearchDirectory is also exported so it can be used
elsewhere to obtain the wasi-sdk libdir and pass to the dyld script.

This commit adds the wasm dynamic linker implementation, as well as
ghci logic to call it and hadrian logic to install it to the correct
location. See the top-level note in utils/jsffi/dyld.mjs for more
details.

This commit makes ghc-bin use dynamic way when it is doing interactive
stuff on certain targets whose RTS linker can only handle dynamic
code.

This commit fixes checkNonStdWay to ensure that for targets whose RTS
linker can only load dynamic code, the dynamic way of object is
selected.

This commit fixes dynamic_too_enable for targets whose RTS linker can
only load dynamic code.

This commit ensures static archives are picked when linking .wasm
modules which are supposed to be fully static, even when ghc may be
invoked with -dynamic, see added comment for explanation.

This commit ensures the GHC driver never passes any RPATH-related
link-time flags on wasm, which is not supported at all.

This commit adds necessary link-time flags for wasm shared libs, see
added comments for detailed explanation.

This commit adds necessary compile-time flags when compiling for wasm
PIC mode, see added comment for detailed explanation.

This commit fixes the handling of dynamic CLabels for the wasm
backend. Just do the simplest handling: preserve the original CLabel,
both unreg/NCG backends can handle them properly without issue.

This commit use the interpreterDynamic predicate in preloadLib to
decide if we should do dynLoadObjs instead of loadObj. Previously we
used hostIsDynamic which was only written with non-cross internal
interpreter in mind.

The testsuite is also adjusted to remove hard-wired -fPIC flag for
cbits (doesn't work in i386 RTS linker in vanilla way, #25260) and
properly pass ghc_th_way_flags to ghc.

Previously, -fexternal-interpreter is broken for JS backend, since GHC
would attempt to launch a non-existent ghc-iserv* executable. This
commit fixes it by adjusting pattern matching order in
setTopSessionDynFlags.

This commit fixes T16180 on wasm once TH support is flipped on. The
fix is simply adding right asm code for wasm.

This commit marks T2615 as skip on wasm, given LD_* environment
variables aren't supported on wasm anyway.

This commit revises boilerplate.mk in testsuite as well as a few other
places, to ensure the tests that do make use of $(ghciWayFlags) can
receive the right $(ghciWayFlags) from testsuite driver config.

This commit skips a few ghc api tests on wasm, since they would
attempt to spawn processes inside wasm, which is not supported at all.

This commit fixes shared library size tests (e.g. array_so in
testsuite/tests/perf/size/all.T) when testing cross ghc. Previously,
if shared library file extension of host and target differs, those
tests will fail with framework errors due to not finding the right
files.

This commit takes config.interp_force_dyn into consideration when
setting up TH/ghci way flags.

This commit implements req_plugins predicate to indicate that the test
requires plugin functionality. Currently this means cross GHC is
disabled since internal-interpreter doesn't work in cross GHC yet.

This patch disables CPU feature detection logic when testing cross
GHC, since those features don't make sense for the target anyway.

This patch implements the targetRTSLinkerOnlySupportsSharedLibs
predicate in hadrian. Its definition in hadrian is the single source
of truth, and the information propagates to ghc settings file, ghc
driver and testsuite driver. It is used in various places to ensure
dynamic dependency is selected when the target RTS linker only
supports loading dynamic code.

This commit implements the config.cross field in the testsuite driver.
It comes from the "cross compiling" ghc info field for both
in-tree/out-of-tree GHC, and is an accurate predicate of whether we're
cross-compiling or not (compared to the precense of target emulator),
and is useful to implement predicates to assert the precense of
internal interpreter (only available on non-cross GHC) for tests that
do require it (e.g. plugins).