Clang driver: can target wasm32 but can’t look up symbols?

[Alan Garny]

Hi,

I have a C++ library that compiles some code 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 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 (using 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.

[Sam Clegg]

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

--
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.

[Alan Garny]

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

[Thomas Lively]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/43636ad6-b9ba-4b37-b903-fc9c217517b3n%40googlegroups.com.

[Alan Garny]

Ok, thanks for the clarifications. I am after an out-of-the-box solution, so I guess I am out of luck here, unfortunately. :(

Alan