Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dwarf not working in developer tools #22525

Open
kohakukun opened this issue Sep 6, 2024 · 9 comments
Open

Dwarf not working in developer tools #22525

kohakukun opened this issue Sep 6, 2024 · 9 comments

Comments

@kohakukun
Copy link
Contributor

kohakukun commented Sep 6, 2024

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 (67fa4c1)

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/[email protected] --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
Copy link
Collaborator

sbc100 commented Sep 6, 2024

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

@kohakukun
Copy link
Contributor Author

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
Copy link
Collaborator

sbc100 commented Sep 9, 2024

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
Copy link
Collaborator

pfaffe commented Sep 9, 2024

@ktran FYI

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

@kohakukun
Copy link
Contributor Author

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
Copy link
Collaborator

sbc100 commented Sep 9, 2024

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
Copy link
Contributor Author

kohakukun commented Sep 10, 2024

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
Copy link
Contributor Author

@sbc100 any idea what could be the issue?

@sbc100
Copy link
Collaborator

sbc100 commented Oct 24, 2024

@pfaffe any chance you could take a look?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants