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: ===================================== rts/RtsToHsIface.c ===================================== @@ -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); View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/38e5246978fea0712115b40b71a8db38... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/38e5246978fea0712115b40b71a8db38... You're receiving this email because of your account on gitlab.haskell.org.