Fix lto0 and thinlto0 tests, e.g. lto0.test_emscripten_get_compiler_setting

[juj]

The following tests are failing for me:

lto0.test_emscripten_get_compiler_setting
lto0.test_pthread_run_script
lto0.test_return_address

thinlto0.test_emscripten_get_compiler_setting
thinlto0.test_pthread_run_script
thinlto0.test_return_address

with errors

cache:INFO: generating system library: libdlmalloc-mt-debug.a... (this will be cached in "libdlmalloc-mt-debug.a" for subsequent builds)
wasm-ld: error: libc-debug.a(stderr.o): attempt to add bitcode file after LTO (stderr)
wasm-ld: error: libc-debug.a(fprintf.o): attempt to add bitcode file after LTO (fprintf)
emcc: error: 'wasm-ld -o test_pthread_run_script.wasm /tmp/emtest_rvts3x5e/emscripten_temp_5ol043gv/test_pthread_run_script_0.o -L/home/clb/buildbot/h12dsi-linux-mint22/emscripten_linux_x64/build/emscripten/main/cache/sysroot/lib/wasm32-emscripten/lto -L/home/clb/buildbot/h12dsi-linux-mint22/emscripten_linux_x64/build/emscripten/main/src/lib -lGL-getprocaddr -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc-debug -lcompiler_rt -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr /tmp/emtest_rvts3x5e/tmpd9n9q0wdlibemscripten_js_symbols.so --strip-debug -u__cxa_atexit --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_get_current --export=emscripten_stack_init --export=_emscripten_stack_alloc --export=__wasm_call_ctors --export=_emscripten_stack_restore --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-if-defined=fflush --export-table -z stack-size=65536 --no-growable-memory --initial-heap=16777216 --no-entry --stack-first --table-base=1' failed (returned 1)
test_pthread_run_script (test_core.lto0.test_pthread_run_script) ... FAIL

at e.g. http://clbri.com:8010/api/v2/logs/21019/raw_inline

I find that libnoexit.a is correctly built with -flto=full, but still, the linker command

wasm-ld -o test_pthread_run_script.wasm /tmp/emtest_rvts3x5e/emscripten_temp_5ol043gv/test_pthread_run_script_0.o -L/home/clb/buildbot/h12dsi-linux-mint22/emscripten_linux_x64/build/emscripten/main/cache/sysroot/lib/wasm32-emscripten/lto -L/home/clb/buildbot/h12dsi-linux-mint22/emscripten_linux_x64/build/emscripten/main/src/lib -lGL-getprocaddr -lal -lhtml5 -lstubs-debug -lnoexit -lc-debug -ldlmalloc-debug -lcompiler_rt -lsockets -mllvm ...

croaks, whereas flipping the order of -lnoexit and -lc-debug fixes the issue.

I don't understand what that is about, everything looks like is getting -flto=full accordingly as far as I can see.

[juj]

Huh, the resulting CI failures are quite unexpected. Different symbols end up being dropped and added in the build altogether. I wonder if there are duplicate symbols being listed in libc and libnoexit.

[sbc100]

Can you add some/one of these (e.g test_emscripten_get_compiler_setting to the list of lto tests run on github CI, see test-core3 in .circleci/config.yml)

[sbc100]

Interesting that lto2 all pass (we run that suite here: https://ci.chromium.org/ui/p/emscripten-releases/builders/ci/linux-test-suites/b8705947941887637105/overview). maybe we should add LTO0 too.

[juj]

This needs more investigation. While this change fixes the original error, it causes some other test expectation errors. Or maybe those test expectation changes are fine.

[juj]

Ok, this PR is not the correct fix. Changing the link order between libc and libnoexit is not right. libnoexit needs to always be linked before libc so that the dummy no-op versions of libnoexit will take precedence.

However, I am pretty stumped with this problem. I am seeing this:

C:\emsdk\emscripten\main\t>wasm-ld.exe -o a.wasm a.o atexit_dummy.o libc-debug.a libdlmalloc-debug.a libcompiler_rt.a jss.so --no-entry
wasm-ld: error: libc-debug.a(stderr.o): attempt to add bitcode file after LTO (stderr)
wasm-ld: error: libc-debug.a(fprintf.o): attempt to add bitcode file after LTO (fprintf)

C:\emsdk\emscripten\main\t>llvm-ar x libdlmalloc-debug.a

C:\emsdk\emscripten\main\t>dir *.o
 Volume in drive C has no label.
 Volume Serial Number is 8847-8E7D

 Directory of C:\emsdk\emscripten\main\t

08/22/2025  01:31 AM             4,668 a.o
08/22/2025  01:39 AM            71,667 dlmalloc.o
08/22/2025  01:39 AM             4,067 sbrk.o
               4 File(s)         83,910 bytes
               0 Dir(s)  368,816,418,816 bytes free

C:\emsdk\emscripten\main\t>wasm-ld.exe -o a.wasm a.o atexit_dummy.o libc-debug.a dlmalloc.o sbrk.o libcompiler_rt.a jss.so --no-entry

C:\emsdk\emscripten\main\t>wasm-ld.exe -o a.wasm a.o atexit_dummy.o libc-debug.a sbrk.o dlmalloc.o libcompiler_rt.a jss.so --no-entry

which doesn't make sense to me at all.

First I link a bunch of .a files, and I get the error.

But then when I extract the .a file, and place the contents of that .a file on the link command line in place of where the .a file resided, the LTO error goes away. (no matter the order in which the .o files in the archive are presented)

This smells to me like some kind of Wasm linker issue - or alternatively I don't understand the semantic model of how LTO linking is supposed to work.

All of these files should be LLVM bitcode, compiled with -flto=full.

The link inputs are at http://oummg.com/dump/emscripten/lto-link-inputs.zip

Failing command line

wasm-ld.exe -o a.wasm a.o libnoexit.a libc-debug.a libdlmalloc-debug.a libcompiler_rt.a jss.so --no-entry

Quite peculiar.

[sbc100]

Maybe just open a bug and disable this test in this mode?

I've dealt with a bunch of issues that look like this before, I can take a look ASAP.