Looks like that asm.js has a duplicate function,
function _memset($0,$1,$2) {
function _memset(ptr, value, num) {
Do you have the bitcode that it was generated from? The bug is probably at the bitcode => asm.js level.
Here is it: libc_test-fe212f5bb0be8707.0.o.zip
I'm using rust 1.18, which uses llvm 4.0...
The same error happens with rust 1.17, which uses llvm 3.9.
I'm not able to test this on emscripten incoming (1.37.13), as I get
$ emcc libc_test-fe212f5bb0be8707.0.o
llc: fastcomp/include/llvm/ADT/ilist_iterator.h:126: llvm::ilist_iterator<OptionsT, IsReverse, IsConst>::reference llvm::ilist_iterator<OptionsT, IsReverse, IsConst>::operator*() const [with OptionsT = llvm::ilist_detail::node_options<llvm::BasicBlock, true, false, void>; bool IsReverse = false; bool IsConst = false; llvm::ilist_iterator<OptionsT, IsReverse, IsConst>::reference = llvm::BasicBlock&]: Assertion `!NodePtr->isKnownSentinel()' failed.
Does that emcc command work for you? Or is there another way I should be reproducing the problem?
Thanks for investigate this.
I can execute emcc libc_test-fe212f5bb0be8707.0.o with sdk-1.37.13-64bit, but there is missing symbol errors.
I think that the best way is to execute the rust compiler... If you do not want to install the rust compiler in your system, you can run it inside a docker container (if you install rustup outside a container, you can uninstall it with the command rustup uninstall, which removes everything that was installed):
git clone https://github.com/malbarbo/libc --branch emscripten
docker run -it -v $(pwd)/libc:/libc ubuntu:16.04
apt-get update && apt-get install curl build-essential
curl https://sh.rustup.rs -sSf | sh # choose option 1
. ~/.profile # set PATH
rustup target add wasm32-unknown-emscripten
# install emscripten
cd /libc
RUSTFLAGS="-Z print-link-args" cargo run --target wasm32-unknown-emscripten -p libc-test
The artifacts are generate in target/wasm32-unknown-emscripten/debug/deps. Setting RUSTFLAGS will print the arguments used to call emcc.
If it doesn't crash for you with that version, then I suspect it's because the sdk build doesn't have assertions, while my local build does. I think we need to find out what's causing those asserts, as they could be the reason for the bug reported here (but it's also possible it's a red herring).
Perhaps is the bitcode old, or being linked with something old? A full rebuild from scratch of all bitcode files might help.
(I could try the rust compiler, but I don't know enough about it to easily debug into it. What I need here is just the emscripten commands it issues.)
Using emscripten incoming I got the same error as you.
I create a a zip file with all required obj files to generate an .js. The command emcc *.o *.rlib works fine, but the command emcc -s WASM=1 *.o *.rlib fail with the original assertion error.
To make it clear, using emcc libc_test-fe212f5bb0be8707.0.o gives the same assertion error you got, but given all object files as parameters works. Is this another issue?
Thanks, now I can see the problem directly. #5299 should fix it.
(I don't see those assertions again, btw - that might be an entirely separate issue. Very strange.)
FWIW I also hit this issue today in a different codebase, and can confirm that #5299 fixed it for me.
Thanks for confirming @rfk. Should be fixed now with that PR merged.
Thanks @kripken!
It would be nice to have this fix.
@kripken When do you think the next patch release might happen?
I tagged 1.37.14 now.
@kripken Thank you!!
Most helpful comment
I tagged
1.37.14now.