I’m general I would not expect the standard JIT setup in LLVM to work with Wasm, even if we solved this particular problem. Even if you could look up a symbol, you wouldn’t be able to execute it without calling out to the embedder to first compile and instantiate a Wasm module containing the code. You would also have to arrange for the function to be placed into the table so you can get a function pointer to it since Wasm is a Harvard architecture. This is all possible in principle to implement, but it definitely will not work out of the box.
On Thu, Jun 8, 2023 at 20:23 Alan Garny <a.ga...@auckland.ac.nz> wrote: > Hi, > > Correct, when I build my library for *X86* or *AArch64*, I JIT *X86* and > *AArch64* code. So, building my library for *wasm32*, I want to JIT > *wasm32* code. > > Regarding your link, yes, I have seen that piece of code when looking for > the error message I am getting. So, how can I ensure that a code section > contains only one function symbol in *wasm32* or am I just out of luck? > (I tried to pass *-ffunction-sections* to the Clang driver, but to no > avail.) > > Alan > > On Friday, 9 June 2023 at 12:38:42 UTC+12 s...@google.com wrote: > >> When you build for non-wasm platforms are you JIT'ing non-wasm code? >> >> This looks like a codegen issue that only affects the wasm backend. The >> error in question occurs if a code section contains more than one function >> symbol. In the wasm backend we expect every function to get its own >> section (i.e. -ffunction-sections is always on). See >> https://github.com/llvm/llvm-project/blob/6ebf7cd7ed1b6502b3b18985f06b213a53381097/llvm/lib/MC/WasmObjectWriter.cpp#L469-L481 >> >> On Thu, Jun 8, 2023 at 5:03 PM Alan Garny <a.g...@auckland.ac.nz> wrote: >> >>> Hi, >>> >>> I have a C++ library that compiles some code >>> <https://github.com/agarny/libopencor/blob/137c9d09a5df1f4af92678ca0971d438f2be730a/src/misc/compiler.cpp#L39-L221> >>> on the fly using an ORC JIT and it all works fine when my library is built >>> for *X86* or *AArch64*, but not when it is built for *wasm32* (using >>> *wasm32-unknown-unknown-elf* as the target triple). For *wasm32*, it >>> looks like the code gets compiled but I can't look up its symbols >>> <https://github.com/agarny/libopencor/blob/137c9d09a5df1f4af92678ca0971d438f2be730a/src/misc/compiler.cpp#L223-L244> >>> and >>> therefore can't run that code. >>> >>> In my browser’s console, I am getting: >>> libopencor.js:8 >>> Compiler::function("initialiseVariables") >>> libopencor.js:8 - Looking up 'initialiseVariables'... >>> libopencor.js:8 LLVM ERROR: section already has a defining function: >>> .text.initialiseVariables >>> put_char @ libopencor.js:8 >>> libopencor.js:8 Aborted() >>> abort @ libopencor.js:8 >>> libopencor.js:8 Uncaught (in promise) RuntimeError: Aborted(). Build >>> with -sASSERTIONS for more info. >>> at abort (libopencor.js:8:6013) >>> at _abort (libopencor.js:8:133020) >>> at libopencor.wasm:0x16693f >>> at libopencor.wasm:0x2589f4e >>> at libopencor.wasm:0xd66725 >>> at libopencor.wasm:0x25782f9 >>> at libopencor.wasm:0x1c426bf >>> at libopencor.wasm:0x25c0cce >>> at libopencor.wasm:0x296f2b6 >>> at libopencor.wasm:0x9d071b >>> >>> I imagine that I must be doing something wrong (when compiling to >>> *wasm32*), but I can’t tell what it is. I tried to google for some >>> sample code that does what I am after, but to no avail. >>> >>> FWIW, the *wasm32* version of my library is built using Emscripten to >>> generate >>> an ES6 module >>> <https://github.com/agarny/libopencor/blob/137c9d09a5df1f4af92678ca0971d438f2be730a/src/CMakeLists.txt#L154-L161> >>> (using *EXPORT_ES6 <https://emsettings.surma.technology/#EXPORT_ES6>*), >>> making it possible to use my library from both Node.js and from a Web >>> browser. It all works fine, except for the fact that I cannot look up >>> symbols and therefore run code that was compiled on the fly. >>> >>> So, would anyone have any idea of what I might be doing wrong? The fact >>> that I am able to do what I want when targeting *X86* or *AArch64* tells >>> me that I should be able to do the same when targeting *wasm32*...? >>> >>> Cheers, Alan. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send an >>> email to emscripten-disc...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/emscripten-discuss/3f08dae1-570e-4cdf-ab37-72b5122c49dfn%40googlegroups.com >>> <https://groups.google.com/d/msgid/emscripten-discuss/3f08dae1-570e-4cdf-ab37-72b5122c49dfn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to emscripten-discuss+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/43636ad6-b9ba-4b37-b903-fc9c217517b3n%40googlegroups.com > <https://groups.google.com/d/msgid/emscripten-discuss/43636ad6-b9ba-4b37-b903-fc9c217517b3n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAJZD_EV7%2BJw8vBnHoqTvVpZTRzSdZr8nz_ROA7nXOjibsurDPQ%40mail.gmail.com.
