Upstream llvm change adds new undefined symbol: __multi3

[sbc100]

This seems to be the change that caused it https://reviews.llvm.org/D65143.

I guess we should somehow filter out these symbols when doing comparisons?

[michaelfranzl]

@sbc100, @sunfishcode, the related pull request #99 only affects the following symbols, but not __multi3 as the issue title says.

__muldc3
__muloti4
__mulsc3
__multc3
__multf3

Since I do indeed see an undefined __multi3 symbol when compiling some C source with https://github.com/llvm/llvm-project/tree/d28af7c654d8db0b68c175db5ce212d74fb5e9bc and wasi-libc revision 659ff41 (tied together in https://github.com/WebAssembly/wasi-sdk/tree/a927856376271224d30c5d7732c00a0b359eaa45), I wonder how this can be fixed?

[sbc100]

#99 will cause the wasi-libc checking code to ignore all undefined symbols that start with __mul .. (including __multi3) when performing its check phase.

What problem are you seeing exactly? Are you seeing the build of wasi-libc fail the check phase? Or are you seeing linker failure due to missing __multi3 symbol? (if you are seeing the latter then that suggests a different issue, perhaps an out-of-date compiler-rt library?)

[michaelfranzl]

I am seeing a linker failure due to an undefined __multi3 symbol coming out of the compilation of a medium-sized C code-base. Supplying --unresolved-symbols=import-functions to wasm-ld allows the linking to succeed, but this is just deferring the problem to the runtime.

I am plainly using wasi-sdk and am doing nothing special. Maybe a recompilation of wasi-sdk will help, but I doubt it.

[sbc100]

What version of wasi-sdk are you using?

The symbol exists at least in wasi-sdk-12 and wasi-sdk-11:

wasi-sdk-12.0 $ ./bin/llvm-nm ./lib/clang/11.0.0/lib/wasi/libclang_rt.builtins-wasm32.a | grep "T __multi3"
00000001 T __multi3

wasi-sdk-11.0 $ ./bin/llvm-nm ./lib/clang/10.0.0/lib/wasi/libclang_rt.builtins-wasm32.a | grep "T __multi3"
00000001 T __multi3

Perhaps somehow libclang_rt.builtins-wasm32.a is now being linked it? (what is the full linker command can clang is generating? you can use -v with clang to show the full linker command).

[michaelfranzl]

I am using the latest wasi-sdk, a927856376271224d30c5d7732c00a0b359eaa45, which pulls in via git submodules:

8af7c654d8db0b68c175db5ce212d74fb5e9bc src/llvm-project (llvmorg-12.0.0)
659ff414560721b1660a19685110e484a081c3d4 src/wasi-libc (heads/main)

It indeed finds __multi3:

./bin/llvm-nm ./lib/clang/12.0.0/lib/wasi/libclang_rt.builtins-wasm32.a | grep "T __multi3"
00000001 T __multi3

Running make check in wasi-sdk is successful (return value 0).

I compile and link separately. Compiling:

../wasi-sdk/build/install/opt/wasi-sdk/bin/clang -c -o file.bc file.c --sysroot ../wasi-sdk/build/install/opt/wasi-sdk/share/wasi-sysroot

Linking:

../wasi-sdk/build/install/opt/wasi-sdk/bin/wasm-ld --no-entry --export-dynamic --unresolved-symbols=import-functions -L ../wasi-sdk/build/install/opt/wasi-sdk/share/wasi-sysroot/lib/wasm32-wasi -lc --import-memory -o app.wasm file1.bc file2.bc etc.

Maybe I'm missing to link some additional library?

[michaelfranzl]

Problem solved. I missed the -lclang_rt.builtins-wasm32 linker flag. Thanks for the hint about libclang_rt.builtins-wasm32.a!

[sbc100]

I recommend using clang to drive your link step to avoid such problems and future proof your build against toolchain changes.

[sbc100]

I also recommend against using the .bc extension for your object files. That is probably old artifact of a older version of emscripten.. and I'm trying to move folks away from using that since it can lead to confusion.