Hi! It's just -g, using -g4 will generate source maps instead of DWARF.
Cheers, Philip On Wednesday, February 10, 2021 at 3:04:18 PM UTC+1 [email protected] wrote: > 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/33fabfd6-520e-4900-bd4b-fee8cb89b6a4n%40googlegroups.com.
