Segfault while linking wasm binaries against libopenlibm

[cardamom-ai]

I have some basic c code to run the naive bayes function, and I'm using libopenlibm for logf and powf.

Building libopenlibm with gnu make and running the executable natively works exactly as expected. However, generating a wasm binary linked against libopenlibm.a results in a SIGSEV and an invalid memory address or null pointer dereference error.

I tried linking in libopenlibm built with gnu make with no arguments and with ARCH=wasm32. Linking the wasm binary against both libraries resulted in the same error as above.

Any suggestions?

[nsajko]

SIGSEV and an invalid memory address or null pointer dereference

In such cases there's two things that one should try first:

• Compile with -ggdb and and run with GDB. Don't know how much that applies to wasm, though
• Compile with ubsan or asan: -g -fsanitize=undefined or -g -fsanitize=address. I think that may even work with wasm. When compiled like so, the execution will stop with a more informative error than otherwise (line number, type of error, etc.)

EDIT: you may need to disable optimizations, too.

[cardamom-ai]

Hey this ended up being a bit of a rat's nest to untangle but I found a workaround.

It turned out my binary wasn't exporting any symbols, because I was failing to find the symbols from openlibm when compiling. The lack of symbols was due to macOS' ranlib not understanding the archive created with make ARCH=wasm32, and stating that the archive had no symbols (even though an alpine docker image had no such issue). (Also there were some errors about the symbol table being too big, so it's possible that was the issue). I found a workaround by just globbing together all the object files with ld -r -o (rather than ar -rcs), and feeding that into my compilations, so I'm generally happy.

I'm not sure if this should be considered a clang bug, or a macOS bug, or what.