Hi Philip This is great news! I read the initial article months ago but was not aware it was now available in the beta Chrome channel.
Anyway, there is probably something in my build script that prevents emscripten from preserving the debug info, because I examined my wasm file with llvm-objdump and it seems I don't have any dwarf sections in there (even though I am using emscripten 2.0.12 and the -g4 flag) There's probably a minor issue lurking somewhere ..... Anyway, THANKS a lot! On Wednesday, February 10, 2021 at 12:32:00 PM UTC+1 [email protected] wrote: > Hi there, > > are the paths truly relative to the build dir or to emcc's working > directory? Maybe you can trick emcc to embed absolute paths by running it > from the filesystem root. Either way, though, you will still end up with > paths that aren't relative to the web server's base directory unless you > serve your entire filesystem. I don't think you'll get around running a > custom web-server. > > That being said, there might be a different approach for you: > https://developers.google.com/web/updates/2020/12/webassembly > With Chrome 89.0.4351 and the DevTools DWARF extension, you can use DWARF > symbols instead of source maps, which not only lets you break and step in > your code, but also lets you look at variables. The blog post also explains > how to deal with paths remapping! > > Cheers, > Philip > > > On Tuesday, February 9, 2021 at 4:34:14 PM UTC+1 [email protected] wrote: > >> Hello >> >> I am trying to add source-level debugging to my (rather big) emscripten >> C++ project. >> >> The browser is trying to access the map file itself at the >> SOURCE_MAP_BASE_URL/MyProject.wasm.map location, where >> SOURCE_MAP_BASE_URL is the string passed to --source-map-base >> >> So far, so good. I can simply start, for instance, python3 -m >> http.server 8080 >> >> The problem is that the map file contains entries relative to the build >> dir : >> >> { >> "version": 3, >> "sources": [ >> >> "../../../../orthanc/OrthancFramework/Sources/DicomFormat/DicomTag.h", >> "../../../src/models/OrthancClient.cpp", >> "../../../src/models/CustomLoaderCache.h", >> >> "../../../../../../../../home/bgo/apps/emsdk/upstream/emscripten/cache/sysroot/include/c++/v1/unordered_map", >> "boost_1_69_0/boost/smart_ptr/weak_ptr.hpp", >> "boost_1_69_0/boost/smart_ptr/shared_ptr.hpp", >> >> >> "../../../../../../../../home/bgo/apps/emsdk/upstream/emscripten/cache/sysroot/include/c++/v1/algorithm", >> ... >> >> >> The browser, when it processes this map file, simply seems to truncate >> all the leading ../ components of the path. >> >> My question is : what is the best way to tackle this issue? >> >> My first gut feeling would be to patch the map file so that all paths are >> absolute, and then serve from my filesystem root. However, it requires the >> map file to be served from a different location, which means I cannot use >> an off-the-shelf server like Python http.server >> >> May I inquire on how you specifically deal with this issue in your own >> projects? Are there extra flags or configuration settings that would allow >> me to configure how the paths are computed or prevent the browser from >> erasing the ".." path components (so that writing my own source server >> becomes, if not trivial, at least possible) ? >> >> Thanks in advance for your help or advice! >> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/a700f992-4819-40d6-82d4-283d87c46574n%40googlegroups.com.
