How to deal with source files location in map files?

[b...@osimis.io]

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!

[Philip Pfaffe]

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

[b...@osimis.io]

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!

[Philip Pfaffe]

Hi!

It's just -g, using -g4 will generate source maps instead of DWARF.

Cheers,

Philip

[b...@osimis.io]

Dear Philip,

you just saved me countless hours of painful printf-based debugging!

If somebody else wants to attempt this, some extra info:

I saw that the wasm file contains the full (Linux) paths to the source files. Since I am using Windows + WSL2 (Ubuntu 20.04), I had two options : 

- Either patch the paths to let my native Chrome open them, which I successfully done with 

/home/bgo/ mapped to //wsl$/Ubuntu-20.04/home/bgo/ and /mnt/c/ mapped to C:/

- Or install an X Server (I am using GWSL that requires no config and is ready to use with WSL2), install the google-chrome-beta package and directly open the source with no remapping. It works fine, too.

I noticed some weird issues where locals inside lambdas are not always visible in the debugger but, mostly, everything works nicely!

I think this tooling will greatly improve the lives of WebAssembly developers!