emscripten-core / emscripten

Emscripten: An LLVM-to-WebAssembly Compiler
Other
25.63k stars 3.29k forks source link

Dwarf not working in developer tools #22525

Open kohakukun opened 1 week ago

kohakukun commented 1 week ago

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 commented 1 week ago

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

kohakukun commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

@ktran FYI

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

kohakukun commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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