Dwarf not working in developer tools

[kohakukun]

Please include the following in your bug report:

Version of emscripten/emsdk: emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.61 (67fa4c16496b157a7fc3377afd69ee0445e8a6e3)

Failing command line in full: Compiling em++ -g -std=gnu++17 -fexceptions -pthread -mbulk-memory -matomics -gdwarf-5 -gsplit-dwarf -gpubnames -MD -MT CMakeFiles/debug_example.dir/debug_example.cpp.o -MF CMakeFiles/debug_example.dir/debug_example.cpp.o.d -o CMakeFiles/debug_example.dir/debug_example.cpp.o -c debug_example.cpp

Linking em++ -g --tracing -s DISABLE_EXCEPTION_CATCHING=0 -pthread -s PTHREAD_POOL_SIZE=8 -sSTACK_SIZE=5MB -sDEFAULT_PTHREAD_STACK_SIZE=2MB -s WASM_BIGINT -sSTACK_OVERFLOW_CHECK=1 -s ALLOW_MEMORY_GROWTH=1 -s MAXIMUM_MEMORY=4GB -s ENVIRONMENT=web,worker -s USE_WEBGPU=1 -s NO_EXIT_RUNTIME=1 -sMODULARIZE=0 -gseparate-dwarf -s ERROR_ON_WASM_CHANGES_AFTER_LINK -s WASM_BIGINT -sASSERTIONS=2 -sUSE_GLFW=3 -s USE_WEBGL2=1 --preload-file /usd_root/lib/usd/@/usd/ --pre-js preloadDevice.js --preload-file resources/File.usdz@File.usdz --preload-file usd_root/plugin/@/plugin/ --preload-file webgpu-env-settings@/webgpu-env-settings --preload-file plugInfo.json@/usd/plugInfo.json CMakeFiles/debug_example.dir/debug_example.cpp.o CMakeFiles/debug_example.dir/camera.cpp.o -o debug_example.js -L/lib -L/usd_root/lib -L/plugin/usd -Wl,--whole-archive -lusd_context -Wl,--no-whole-archive -Wl,--whole-archive -lsdf_context -Wl,--no-whole-archive -Wl,--whole-archive -lusd_pegtl -Wl,--no-whole-archive -Wl,--whole-archive -lusd_garch -Wl,--no-whole-archive -Wl,--whole-archive -lusd_cameraUtil -Wl,--no-whole-archive -Wl,--whole-archive -lusd_geomUtil -Wl,--no-whole-archive -Wl,--whole-archive -lusd_ar -Wl,--no-whole-archive libtint_api.a libtint_api_common.a libtint_utils_ice.a libtint_utils_text.a libtint_lang_wgsl_ast.a libtint_utils_generator.a libtint_utils_rtti.a libtint_lang_core.a libtint_lang_core_constant.a libtint_lang_core_intrinsic.a libtint_lang_core_type.a libtint_utils_id.a libtint_utils_result.a libtint_utils_strconv.a libtint_utils_symbol.a libtint_lang_wgsl.a libtint_lang_wgsl_ast_transform.a libtint_lang_wgsl_intrinsic.a libtint_lang_wgsl_features.a libtint_lang_wgsl_program.a libtint_lang_wgsl_resolver.a libtint_lang_wgsl_sem.a libtint_lang_wgsl_writer_ast_printer.a libtint_lang_spirv_reader.a libtint_lang_spirv_reader_ast_lower.a libtint_lang_spirv_reader_ast_parser.a libtint_utils_debug.a libtint_lang_wgsl_writer.a libtint_utils_diagnostic.a -lglslang -lglslang-default-resource-limits -lMachineIndependent -lSPIRV -lSPIRV-Tools -lSPIRV-Tools-opt -lGenericCodeGen -Wl,--whole-archive -lusd_ts -Wl,--no-whole-archive -Wl,--whole-archive -lusd_vt -Wl,--no-whole-archive -Wl,--whole-archive -lusd_gf -Wl,--no-whole-archive -Wl,--whole-archive -lusd_plug -Wl,--no-whole-archive -Wl,--whole-archive -lusd_work -Wl,--no-whole-archive -Wl,--whole-archive -lusd_trace -Wl,--no-whole-archive -Wl,--whole-archive -lusd_js -Wl,--no-whole-archive -Wl,--whole-archive -lusd_tf -Wl,--no-whole-archive -Wl,--whole-archive -lusd_arch -Wl,--no-whole-archive -losdCPU -losdGPU -ltbb_debug

In this case I get:

[C/C++ DevTools Support (DWARF)] Loading debug symbols for http://localhost:8080/build/debug_example.wasm (via debug_example.wasm.debug.wasm)...

but never get the other message saying that things have been loaded. There is also not other error in the process of compiling or linking nor on the website, which behaves as expected.

If from the previous command I subtract the -Wl,--whole-archive -lsdf_context -Wl,--no-whole-archive library, things seem to work a symbols are loaded.

Following this guide https://developer.chrome.com/blog/faster-wasm-debugging#debug_fission I'm using the dwarf split command since doing otherwise results in Chrome crashing trying to load the debug information. I followed this guife

[sbc100]

Does debugging work for you with a simple hello world program? (does it also work with dwarf split?)

[kohakukun]

Yes, the whole setup works if I remove -Wl,--whole-archive -lsdf_context -Wl,--no-whole-archive . I see the debug files and all the information.

[sbc100]

I that case I imagine you could be running into some kind of limit where including that whole archive pushes you over that limit. @pfaffe WDYT?

BTW, what is the reason you are using --whole-archive around your libraries?

[pfaffe]

@ktran FYI

Hard to say if we're hitting limits. How big are the wasm files in question?

[kohakukun]

I think it is not a size limit because other combination of libraries with a bigger size seems to work. With that additional library is only 19M for the wasm and 81M for the wasm.debug. But my hope is to get to something like 500mb in wasm.debug.

I'm using --whole-archive because the library I'm linking has some plugin registration system with some global static objects. This is some more information on that topic https://github.com/PixarAnimationStudios/OpenUSD/blob/release/BUILDING.md#linking-whole-archives

[sbc100]

I think it is not a size limit because other combination of libraries with a bigger size seems to work. With that additional library is only 19M for the wasm and 81M for the wasm.debug. But my hope is to get to something like 500mb in wasm.debug.

In that case, would it be possible to attach the failing .wasm + .wasm.debug?

I'm using --whole-archive because the library I'm linking has some plugin registration system with some global static objects. This is some more information on that topic https://github.com/PixarAnimationStudios/OpenUSD/blob/release/BUILDING.md#linking-whole-archives

Thanks, that makes perfect sense.

[kohakukun]

I had to break down the files to be able to attach it. The first one is just the debug.wasm and the second is the rest of the files. I included the python script for the server since it needs some headers for using SharedArrays. You would just need to copy the debug.wasm into the other decompressed folder and call python wasm-server.py usdviewweb.wasm.debug.wasm.zip not_working_rest.zip

This one is working for reference:

working.zip

[kohakukun]

@sbc100 any idea what could be the issue?

[sbc100]

@pfaffe any chance you could take a look?