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.ga...@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-discuss+unsubscr...@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/CAL_va297w9UKoN%2BV41di_UAEFwj8b%3DAHi5gPH5tLE8LNx-dv9w%40mail.gmail.com.
