undefined symbol with upstream compiler from 1.38.46 & WASM_OBJECT_FILES=0

[John Harvey]

This is moving one of the items discussed in the 1.39.0 thread to its own topic. 

From 1.38.46-upstream when linking our largish library we get the following error produced and this still happens with 1.39.2:-

wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc: undefined symbol: __threwValue
wasm-ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
shared:ERROR: 'd:/compilers/emscripten-1.39.2-upstream/upstream/bin\wasm-ld.exe @d:\users\jpharvey\appdata\local\temp\emscripten_5umhgn.rsp' failed (1)

The code is built & linked with a consistent set of compiler flags 

em++ --bind -s ALLOW_MEMORY_GROWTH=1 -s NO_EXIT_RUNTIME=1 -s FULL_ES2=1 --memory-init-file 0 -s ERROR_ON_UNDEFINED_SYMBOLS=1 -s DISABLE_EXCEPTION_CATCHING=0 -s EMBIND_STD_STRING_IS_UTF8=0 -s AGGRESSIVE_VARIABLE_ELIMINATION=1 -s EVAL_CTORS=0 -s WASM_OBJECT_FILES=0 -s WASM=1 -O3 -s ASSERTIONS=1 -s DEMANGLE_SUPPORT=1 -DNDEBUG=1 -s DISABLE_EXCEPTION_CATCHING=0 --std=c++14 --llvm-lto 1

It links fine if i remove -s WASM_OBJECT_FILES=0

It linked fine with -s WASM_OBJECT_FILES=0 using 1.38.45

__threwValue does appear to exist as a symbol in libcompiler_rt.bc

\compilers\emscripten-1.39.2-upstream\upstream\bin\llvm-nm d:\users\jpharvey\.emscripten_cache_1.39.2-upstream\wasm-bc\libcompiler_rt.bc  | grep -i threw
-------- D __THREW__
-------- D __threwValue
-------- T setThrew

Not sure how to debug this further. I guess it started when this code for __threwValue was merged into libcompiler_rt instead of being in its own file?

Any suggestions on how to help get to the bottom of this

[Alon Zakai]

Does it work if you remove --llvm-lto 1 during link?

For checking if this is a regression, please try 1.38.45-upstream in comparison to 1.39.0-upstream (as the default backend changed there, so if not specifying the backend, older versions use the other one).

It would be good to get a testcase of this, if you can provide that.

--
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/c5b797a2-a168-46dd-b40a-d5d91ddbdd3f%40googlegroups.com.

[John Harvey]

1.38.45-upstream works fine.

1.38.46-upstream has the same errors as 1.39.0 & .2

I am 90% certain changing the lto flags makes no difference but will re-run that check.

Test case is going to be hard but i'll see if i can get something smaller.

[John Harvey]

Tested again and yes this is caused by LTO=1 & WASM_OBJECT_FILES=0 if i link without LTO then it is fine.

Trying to get a small example is proving trickier. but will try to find some time to see if i can find something.

[Sam Clegg]

Interesting, it looks like you have found a bug in LTO here.
Hopefully we can find a smaller repro case.

On Fri, Nov 8, 2019 at 5:53 AM 'John Harvey' via emscripten-discuss

> --
> 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/3d5dc887-cb3e-4794-bfcb-aa6051a6d49f%40googlegroups.com.

[John Harvey]

I have shared a zip file with code that demonstrates the problem.

It's too large to attach so is shared at https://drive.google.com/file/d/1K7jzX1_alAv-T6js7JWaGMgNkiwkMwfs/view?usp=sharing

The code is all built consistently with the same flags i use here.

If i link it with --llvm-lto we see the problem. If i just use -flto then it links fine. I am building on windows so have included a batch file build.bat which just does the linking both ways and the zip contains all the object files needed to reproduce the problem.

I hope this is enough for someone to investigate it.