Dear devs, For the record, I gave resolution to this question in [1]. In this case, studying the commit introducing CStub was enlightening to update inline-java by imitating related updates in GHC.
Best, Facundo [1]: https://github.com/tweag/inline-java/issues/205 On Mon, Jul 14, 2025 at 9:28 AM Facundo Domínguez < facundo.doming...@tweag.io> wrote: > Dear devs, > > I upgraded inline-java [1] to use GHC 9.10.2 recently. inline-java has a > GHC plugin responsible for embedding JVM bytecode in Haskell modules. This > message is to consult on the most appropriate way to do it. > > The byte code is placed in a C literal array of bytes, and the C code is > added in mg_foreign together with C constructor functions that run when > loading the module to add the bytecode to a global bytecode table [2]. The > global bytecode table is then fed to the JVM when initializing inline-java. > > The GHC API in 9.10.2 requires creating a CStub which does have a field to > indicate constructor functions [3], but I wouldn't know how to create the > CLabels it needs. So instead, I just put the constructor functions in the > getCStub field, and set getInitializers to an empty list. The constructor > functions seem to run at initialization just the same. > > Should inline-java do this differently? > > Thanks in advance! > Facundo > > [1] https://github.com/tweag/inline-java > [2] > https://github.com/tweag/inline-java/blob/c6b590c29ef9190164dec3a235b8e386c537bd29/src/Language/Java/Inline/Plugin.hs#L87 > [3] > https://gitlab.haskell.org/ghc/ghc/-/blob/3c37d30b07fc85fe09452f4ce250aec42cb1d2e4/compiler/GHC/Types/ForeignStubs.hs#L23 > > data CStub = CStub { getCStub :: SDoc > , getInitializers :: [CLabel] > -- ^ Initializers to be run at startup > -- See Note [Initializers and finalizers in Cmm] in > -- "GHC.Cmm.InitFini". > , getFinalizers :: [CLabel] > -- ^ Finalizers to be run at shutdown > } > > -- > All views and opinions expressed in this email message are the personal > opinions of the author and do not represent those of the organization or > its customers. > -- All views and opinions expressed in this email message are the personal opinions of the author and do not represent those of the organization or its customers.
_______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-le...@haskell.org
