[Git][ghc/ghc][wip/optim-faststring] compiler: Always load GHC.Data.FastString optimised into GHCi

[Matthew Pickering (@mpickering)]

Matthew Pickering pushed to branch wip/optim-faststring at Glasgow Haskell Compiler / GHC


Commits:
5ca004bd by Matthew Pickering at 2025-01-29T11:33:58+00:00
compiler: Always load GHC.Data.FastString optimised into GHCi

The FastString table is shared between the boot compiler and interpreted
compiler. Therefore it's very important the representation of
`FastString` matches in both cases. Otherwise, the interpreter will read
a FastString from the shared variable but place the fields in the wrong
place which leads to segfaults.

Ideally this state would not be shared, but for now we can always
compile both with `-O2` and this leads to a working interpreter.

- - - - -


1 changed file:

- compiler/GHC/Data/FastString.hs


Changes:

=====================================
compiler/GHC/Data/FastString.hs
=====================================
@@ -2,10 +2,19 @@
 {-# LANGUAGE MagicHash #-}
 {-# LANGUAGE UnboxedTuples #-}
 {-# LANGUAGE UnliftedFFITypes #-}
+{-# LANGUAGE CPP #-}
 
 {-# OPTIONS_GHC -O2 -funbox-strict-fields #-}
+#if MIN_VERSION_GLASGOW_HASKELL(9,8,0,0)
+{-# OPTIONS_GHC -fno-unoptimized-core-for-interpreter #-}
+#endif
 -- We always optimise this, otherwise performance of a non-optimised
 -- compiler is severely affected
+--
+-- Also important, if you load this module into GHCi then the data representation of
+-- FastString has to match that of the host compiler due to the shared FastString
+-- table. Otherwise you will get segfaults when the table is consulted and the fields
+-- from the FastString are in an incorrect order.
 
 -- |
 -- There are two principal string types used internally by GHC:



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/5ca004bd9dc2e80dae3ca559f286f97c8619bc98

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/5ca004bd9dc2e80dae3ca559f286f97c8619bc98
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20250129/243ca516/attachment-0001.html>