wasm64: i32.store8[0] expected type i64

[jijjijj]

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 5.0.7 (263db4cffa6f9fc2ec514a70abac81362ea41849)
clang version 23.0.0git (https:/github.com/llvm/llvm-project 7b58716d96c3ae4c0c4e6f72e29b16137bb6224b)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/_/.conan2/p/b/emsdk0a8073caa1b86/p/bin/upstream/bin

Full link command and output with -v appended:

/home/_/.conan2/p/b/emsdk0a8073caa1b86/p/bin/upstream/emscripten/em++ -stdlib=libc++ -ffunction-sections -gdwarf -sMEMORY64=1 -g -gdwarf -O0 -flto=thin -sALLOW_MEMORY_GROWTH=1 -sMEMORY64=1 -sNO_DISABLE_EXCEPTION_CATCHING -Xlinker --gc-sections -msimd128 src/core/client/exec/CMakeFiles/core.client.exec.dir/main.cpp.o -o src/core/client/exec/client.js -L/home/_/.conan2/p/b/highwa76ccc51f0794/p/lib   -L/home/_/.conan2/p/b/spdlo1200e34525b02/p/lib -Wl,--whole-archive  src/core/client/libwrapper/libwrapper.a  -Wl,--no-whole-archive  3rdparty/highway/highway.modules.a  /home/_/.conan2/p/b/highwa76ccc51f0794/p/lib/libhwy_contrib.a  /home/_/.conan2/p/b/highwa76ccc51f0794/p/lib/libhwy.a  -Wl,--whole-archive  src/core/client/libclient/libclient.a  -Wl,--no-whole-archive  3rdparty/stduuid/stduuid.modules.a  -Wl,--whole-archive  src/shared/util/libutil/libutil.a  -Wl,--no-whole-archive   3rdparty/spdlog/spdlog.modules.a  /home/_/.conan2/p/b/spdlo1200e34525b02/p/lib/libspdlogd.a  -Wl,--whole-archive  src/shared/common/libcommon/libcommon.a  -Wl,--no-whole-archive  3rdparty/std/std.modules.a  3rdparty/ms-gsl/ms-gsl.modules.a  -lidbfs.js

Output when running node client.js:

failed to asynchronously prepare wasm: CompileError: WebAssembly.instantiate(): Compiling function #216:"eng::sample_client@_.client()" failed: i32.store8[0] expected type i64, found local.tee of type i32 @+54254
Aborted(CompileError: WebAssembly.instantiate(): Compiling function #216:"eng::sample_client@_.client()" failed: i32.store8[0] expected type i64, found local.tee of type i32 @+54254)
/build/ems-debug-wasm-cov/src/core/client/exec/client.js:577
  var e = new WebAssembly.RuntimeError(what);
          ^

RuntimeError: Aborted(CompileError: WebAssembly.instantiate(): Compiling function #216:"eng::sample_client@_.client()" failed: i32.store8[0] expected type i64, found local.tee of type i32 @+54254)
    at abort (/build/ems-debug-wasm-cov/src/core/client/exec/client.js:577:11)
    at instantiateArrayBuffer (/build/ems-debug-wasm-cov/src/core/client/exec/client.js:642:5)
    at async createWasm (/build/ems-debug-wasm-cov/src/core/client/exec/client.js:740:16)

Node.js v25.9.0

The code that triggers this behaviour, if you remove && val_b everything's fine.

module _;

import std;
import :client;

namespace eng {
int sample_client() {
    const bool val_a = false;
    const bool val_b = false;
    if (val_a && val_b) {
        return 3;
    }
    return 6;
}

int enter(int /*argc*/, char** /*argv*/) {
    std::cout << sample_client() << std::endl;

    return 6;
}
}

What could be the reason for this?

[sbc100]

Using a slightly simplified version of that above code I was not able to reproduce:

$ cat test.cc
#include <iostream>


int sample_client() {
    const bool val_a = false;
    const bool val_b = false;
    if (val_a && val_b) {
        return 3;
    }
    return 6;
}

int main(int /*argc*/, char** /*argv*/) {
    std::cout << sample_client() << std::endl;

    return 6;
}
./emcc test.cc -sMEMORY64=1 -g -gdwarf -O0 -flto=thin
$ ~/bin/node-v25.4.0-linux-x64/bin/node a.out.js
6

Are you able to share a full failing example?

[jijjijj]

Here, this works:

em++ -sMEMORY64=1 -g -gdwarf -O0 -flto=thin -target=wasm64-unknown-emscripten -msimd128 -fprofile-instr-generate -fcoverage-mapping test.cc

this doesn't (added -fcoverage-mcdc):

em++ -sMEMORY64=1 -g -gdwarf -O0 -flto=thin -target=wasm64-unknown-emscripten -msimd128 -fprofile-instr-generate -fcoverage-mapping -fcoverage-mcdc test.cc

[sbc100]

Thank you! I was able to reproduce. I imagine the problems is that -fcoverage support is just non-existent/broken. I will investigate more.

[sbc100]

Indeed, it looks like coverage-mapping is not yet supported with MEMORY64:

emscripten/test/test_core.py

Line 9818 in 00f352d

@no_wasm64('TODO: fcoverage in memory64')

Maybe I'll update that comment to point directly to this bug..

[jijjijj]

@sbc100 is it supported with wasm32? Because I'm getting incosistent behaviour with -fprofile-instr-generate and -fcoverage-mapping + wasm32 and I'm not sure what the reason is

[sbc100]

I'm not sure how well its supported but we do have at least one test for it:

emscripten/test/test_core.py

Lines 9821 to 9844 in 926047d

	def test_fcoverage_mapping(self):
	expected = '''\
	1| |/*
	2| | * Copyright 2016 The Emscripten Authors. All rights reserved.
	3| | * Emscripten is available under two separate licenses, the MIT license and the
	4| | * University of Illinois/NCSA Open Source License. Both these licenses can be
	5| | * found in the LICENSE file.
	6| | */
	7| |
	8| |#include <stdio.h>
	9| |
	10| 1|int main() {
	11| 1| printf("Hello, world!\\n");
	12| 1| return 0;
	13| 1|}
	'''
	self.set_setting('NODERAWFS')
	self.set_setting('EXIT_RUNTIME')
	self.do_core_test('test_hello_world.c', cflags=['-fprofile-instr-generate', '-fcoverage-mapping', '-g'])
	self.assertExists('default.profraw')
	self.run_process([LLVM_PROFDATA, 'merge', '-sparse', 'default.profraw', '-o', 'out.profdata'])
	self.assertExists('out.profdata')
	self.assertEqual(expected, self.run_process([LLVM_COV, 'show', 'test_hello_world.wasm', '-instr-profile=out.profdata'], stdout=PIPE).stdout)

I'm not sure how much folks are actually using it though so it could well be that our tests our insufficient and there are hidden issues.

[jijjijj]

Got it, thanks

[jijjijj]

My problem with wasm32 coverage was resolved by linking with -Wl,--whole-archive -lcompiler_rt -Wl,--no-whole-archive options. AFAIK compiler_rt should be linked with automatically if coverage is enabled but for some reason it wasn't. Maybe it's LLVM's problem, maybe my setup's

[sbc100]

What happens if you don't add whole-archive? Are you getting some kind of undefined symbol error? Maybe you could share your full build command and how it fails?

[jijjijj]

Build and linking work fine (as in they don't fail). It's just that in the resulting .wasm binary there are no _llvm_* symbols (except for DATA ones) and as a result no .profraw file gets created after I run the said binary.

About the full build command - the problem is that some of my binaries build fine (with the _llvm_* symbols), some don't - and I'm not sure what's the difference between them. May be the presence of some 3rd party dependency that pulls in the compiler_rt

[jijjijj]

Oh, or do you mean what happens if I don't add the whole-archive but add the -lcompiler_rt?

[sbc100]

compiler_rt is always include by default (unless you specify something like -nostdlib, which I doubt you are doing).

[jijjijj]

Tried removing whole-archive and the abovementioned situation with lack of __llvm symbols happens. Here's what llvm-objdump -t my.wasm | grep llvm gives me:

00000000       F *UND*  00000000 llvm_eh_typeid_for
0001a788 l     O DATA   00000000 __llvm_prf_bits
0001a788 l     O DATA   00000250 __llvm_prf_cnts
0001a9d8 l     O DATA   00000d20 __llvm_prf_data
0001b6f8 l     O DATA   0000081b __llvm_prf_names

While in normal binaries the following symbols are present:

00000000       F *UND*  00000000 llvm_eh_typeid_for
00007557 l     F CODE   00000009 __llvm_profile_begin_data
00007560 l     F CODE   00000009 __llvm_profile_end_data
00007569 l     F CODE   00000009 __llvm_profile_begin_names
00007572 l     F CODE   00000009 __llvm_profile_end_names
0000757b l     F CODE   00000009 __llvm_profile_begin_vtabnames
00007584 l     F CODE   00000009 __llvm_profile_end_vtabnames
0000758d l     F CODE   00000009 __llvm_profile_begin_vtables
00007596 l     F CODE   00000009 __llvm_profile_end_vtables
0000759f l     F CODE   00000009 __llvm_profile_begin_counters
000075a8 l     F CODE   00000009 __llvm_profile_end_counters
000075b1 l     F CODE   00000009 __llvm_profile_begin_bitmap
000075ba l     F CODE   00000009 __llvm_profile_end_bitmap
000075c3 l     F CODE   00000009 __llvm_profile_begin_vnodes
000075cc l     F CODE   00000009 __llvm_profile_end_vnodes
000075d5 l     F CODE   00000005 __llvm_write_binary_ids
000075e6 l     F CODE   0000000d __llvm_profile_get_magic
000075f3 l     F CODE   0000000c __llvm_profile_get_num_padding_bytes
000075ff l     F CODE   0000000c __llvm_profile_get_version
0000760b l     F CODE   00000019 __llvm_profile_is_continuous_mode_enabled
00007624 l     F CODE   0000000e __llvm_profile_disable_continuous_mode
00007632 l     F CODE   00000051 __llvm_profile_get_size_for_buffer
00007683 l     F CODE   000000cb __llvm_profile_get_size_for_buffer_internal
0000774e l     F CODE   0000000f __llvm_profile_get_num_data
0000775d l     F CODE   00000014 __llvm_profile_get_data_size
00007771 l     F CODE   0000000c __llvm_profile_get_num_vtable
0000777d l     F CODE   00000009 __llvm_profile_get_vtable_section_size
00007786 l     F CODE   0000001a __llvm_profile_counter_entry_size
000077a0 l     F CODE   0000003c __llvm_profile_get_num_counters
000077dc l     F CODE   00000054 __llvm_profile_get_counters_size
00007830 l     F CODE   00000009 __llvm_profile_get_num_bitmap_bytes
00007839 l     F CODE   00000009 __llvm_profile_get_name_size
00007842 l     F CODE   00000062 __llvm_profile_get_padding_sizes_for_counters
000081fb l     F CODE   00000051 __llvm_profile_recursive_mkdir
00008624 l     F CODE   0000016d __llvm_profile_check_compatibility
00008791 l     F CODE   00000395 __llvm_profile_merge_from_buffer
00008c0c l     F CODE   000002ad __llvm_profile_instrument_target_value
00009d63 l     F CODE   00000092 __llvm_profile_initialize
00009dff l     F CODE   00000468 __llvm_profile_write_file
0000d7f7 g     F CODE   0000000d __llvm_profile_runtime_user
0001b1f8 l     O DATA   00000001 __llvm_prf_bits
0001b200 l     O DATA   00000278 __llvm_prf_cnts
0001b478 l     O DATA   00000d80 __llvm_prf_data
0001c1f8 l     O DATA   0000085a __llvm_prf_names

[sbc100]

Any why those symbols might not be being pulling ? I guess that the compiler should be generating calls to these functions which should pull them in automatically.

In our simple test test_fcoverage_mapping they seems to be included just fine:

$ ./test/runner core0.test_fcoverage_mapping
$ llvm-objdump -t out/test/test_hello_world.wasm | grep llvm
000005a8 g     F CODE	0000000d __llvm_profile_runtime_user
00005d9a l     F CODE	00000009 __llvm_profile_begin_data
00005da3 l     F CODE	00000009 __llvm_profile_end_data
00005dac l     F CODE	00000009 __llvm_profile_begin_names
00005db5 l     F CODE	00000009 __llvm_profile_end_names
00005dbe l     F CODE	00000009 __llvm_profile_begin_vtabnames
00005dc7 l     F CODE	00000009 __llvm_profile_end_vtabnames
00005dd0 l     F CODE	00000009 __llvm_profile_begin_vtables
00005dd9 l     F CODE	00000009 __llvm_profile_end_vtables
00005de2 l     F CODE	00000009 __llvm_profile_begin_counters
00005deb l     F CODE	00000009 __llvm_profile_end_counters
00005df4 l     F CODE	00000009 __llvm_profile_begin_bitmap
00005dfd l     F CODE	00000009 __llvm_profile_end_bitmap
00005e06 l     F CODE	00000009 __llvm_profile_begin_vnodes
00005e0f l     F CODE	00000009 __llvm_profile_end_vnodes
00005e18 l     F CODE	00000005 __llvm_write_binary_ids
00005e29 l     F CODE	0000000d __llvm_profile_get_magic
00005e36 l     F CODE	0000000c __llvm_profile_get_num_padding_bytes
00005e42 l     F CODE	0000000c __llvm_profile_get_version
00005e4e l     F CODE	00000019 __llvm_profile_is_continuous_mode_enabled
00005e67 l     F CODE	0000000e __llvm_profile_disable_continuous_mode
00005e75 l     F CODE	00000051 __llvm_profile_get_size_for_buffer
00005ec6 l     F CODE	000000cb __llvm_profile_get_size_for_buffer_internal
00005f91 l     F CODE	0000000f __llvm_profile_get_num_data
00005fa0 l     F CODE	00000014 __llvm_profile_get_data_size
00005fb4 l     F CODE	0000000c __llvm_profile_get_num_vtable
00005fc0 l     F CODE	00000009 __llvm_profile_get_vtable_section_size
00005fc9 l     F CODE	0000001a __llvm_profile_counter_entry_size
00005fe3 l     F CODE	0000003c __llvm_profile_get_num_counters
0000601f l     F CODE	00000054 __llvm_profile_get_counters_size
00006073 l     F CODE	00000009 __llvm_profile_get_num_bitmap_bytes
0000607c l     F CODE	00000009 __llvm_profile_get_name_size
00006085 l     F CODE	00000062 __llvm_profile_get_padding_sizes_for_counters
000061a6 l     F CODE	0000016d __llvm_profile_check_compatibility
00006313 l     F CODE	00000395 __llvm_profile_merge_from_buffer
00008422 l     F CODE	00000092 __llvm_profile_initialize
000084be l     F CODE	00000468 __llvm_profile_write_file
00009152 l     F CODE	00000051 __llvm_profile_recursive_mkdir
000095b7 l     F CODE	000002ad __llvm_profile_instrument_target_value
00011678 l     O DATA	00000008 __llvm_prf_cnts
00011680 l     O DATA	00000030 __llvm_prf_data
000116b0 l     O DATA	0000000e __llvm_prf_names

This file looks like its trying to do register is static constructor so maybe its somehow not being registered in failing case https://github.com/emscripten-core/emscripten/blob/main/system/lib/compiler-rt/lib/profile/InstrProfilingRuntime.cpp?

[sbc100]

Yes, in the normal case it looks like the runtime gets pulled in via undefined symbols to __llvm_profile_runtime which is defined in InstrProfilingRuntime.cpp and has a static constructor that pulls in the runtime init code.

You can add -Wl,--trace-symbol=__llvm_profile_runtime to see how this symbol is references by your compiled objects files which then causes the compiler-rt symbol to be included:

$ emcc test/core/test_hello_world.c -o test_hello_world.js -sNO_DEFAULT_TO_CXX -sNODERAWFS -sEXIT_RUNTIME -Wclosure -Werror -Wno-limited-postlink-optimizations -O0 -fprofile-instr-generate -fcoverage-mapping -g -Wl,--trace-symbol=__llvm_profile_runtime
/tmp/emscripten_temp_2o4zsl5w/test_hello_world.o: reference to __llvm_profile_runtime
/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libcompiler_rt.a(InstrProfilingRuntime.o): definition of __llvm_profile_runtime