GitLab

Cheng Shao pushed to branch wip/T26166 at Glasgow Haskell Compiler / GHC

Commits:

38e52469
by Cheng Shao at 2025-10-17T15:21:54+02:00
```
chore: revise existing notes
```

2 changed files:

rts/RtsToHsIface.c
rts/wasm/JSFFI.c

Changes:

@@ -18,16 +18,17 @@
   *         // etc.
   *     };
+  *
 - * `ghc_hs_iface` is initialized during program loading via the
 - * `init_ghc_hs_iface` constructor in `ghc-interface`
 + * `ghc_hs_iface` is initialized via the `init_ghc_hs_iface` function
 + * in `ghc-internal` cbits, when it is invoked by `hs_init_ghc` during
 + * GHC RTS initialization:
+  *
 - *     const struct HsIface the_hs_iface = {
 + *     struct HsIface the_hs_iface = {
   *         .runIO = &ghczminternal_GHCziInternalziTopHandler_runIO_closure,
   *         .Z0T = &ghczminternal_GHCziInternalziTuple_Z0T_closure,
   *         // etc.
   *     };
+  *
 - *     void __attribute__((constructor)) init_ghc_hs_iface() {
 + *     void init_ghc_hs_iface(void) {
   *         ghc_hs_iface = &the_hs_iface;
   *     }
+  *
@@ -36,7 +37,7 @@
   * side-effect of making the interface between the RTS and `ghc-internal`
   * explicit.
+  *
 - * Note that the ((constructor)) symbol is explicitly included in the final
 + * Note that the init_ghc_hs_iface symbol is explicitly included in the final
   * binary via the linker flag `-uinit_ghc_hs_iface`, when an executable is
   * linked against ghc-internal by GHC.
+  *
@@ -45,11 +46,15 @@
   * (since, otherwise, only objects members which provide undefined symbols
   * needed by the executable are included in the final object).
+  *
 - * When `ghc-internal` is a dynamic dependency of an executable, the
 - * constructor will run when the shared object for `ghc-internal` is loaded.
 - * When the executable is statically linked against `ghc-internal`, the
 - * constructor will be run when the program is loaded (since the constructor
 - * symbol was forcibly included as described in the paragraph above).
 + * CAUTION: there may be constructors invoked before hs_init_ghc, and
 + * those constructors will see an uninitialized ghc_hs_iface! For now
 + * we're fine: when GHC generates a constructor that references
 + * certain closures or info tables, the generated references don't go
 + * through ghc_hs_iface redirection, and they are not forward
 + * references to other objects not compiled yet. Still, always keep
 + * the no-ghc_hs_iface restriction in mind when doing work related to
 + * constructors, be it the compiler-generated ones or explicitly
 + * written ones in RTS.
   */
  #include "Rts.h"

rts/wasm/JSFFI.c

@@ -68,6 +68,15 @@ static void __init_ghc_hs_iface_jsffi(void) {
  // Therefore, on wasm32, we designate priority 101 to ctors generated
  // by the GHC codegen, and priority 102 to the initialization logic
  // here to ensure hs_init_ghc() sees everything it needs to see.
 +//
 +// It's simpler when it comes to shared libraries: we'll need to load
 +// them via dyld written in JS anyway, and hence we always compile the
 +// rts shared library with JSVal functionality. The constructors here
 +// are only for non-shared objects, so that the user would only need
 +// to invoke _initialize for all the RTS initialization logic to be
 +// done before invoking user-specified exports; for the shared library
 +// case, we explicitly export __ghc_wasm_jsffi_init to be invoked by
 +// dyld, after at least rts & ghc-internal has been loaded.
  #if defined(__PIC__)
  __attribute__((export_name("__ghc_wasm_jsffi_init"))) void __ghc_wasm_jsffi_init(void);