Need guidance on wasm:// vs file:// schema for debugging symbols

[rubu]

I guess this is more of a request for help/guidance than an actual issue. But here goes.

I need an advice on how WebAssembly binaries produced with emscripten can store their debug symbols to understand why my particular case does not work while a trivial one does.

So I was trying to test this AV1 WebAssembly port but it failed with errors in malloc so I wanted to debug it. I added -g4 and -source-map-base which gave me the ability to see C code, but none of the variables, all the variables in scope had the WebAssembly names - var0 etc.

I watched this Youtube video, took Chrome Canary + the mentioned Chrome DevTools WebAssembly Extension. I made a trivial example where I compiled a single file with a trivial main() doing some printing. Initially it did not show variables but when I added -gseparate-dwarf then I got variables as well. What I saw was that the browser did a lot of file:// based requests and Chrome asked for permissions for file access on the drive (I would assume after loading the dwarf file it got the paths, since llvm-dwarfdump showed full paths in the .debug.wasm file and the original .wasm file had a external_debug_info section pointing to the separate .wasm file). The biggest difference I can see is that in this case I generated a .html as the output from emcc, but as far as I can see it has similar glue code to what the library that I am trying to test already has.

Now, I tried doing the same with that project - I forked it, added a debug build with -gseparate-dwarf but the Chrome DevTools WebAssembly Extension now complains that it cannot load the symbols. But there is a big difference - if with the previous trivial sample the messages were always like Trying to load simbols for <some C file path> via (<my dwarf wasm file path>), then now instead of the C file path it has a path like wasm://wasm/<some hex word> and I also see the same scheme (wasm://) in the source inspector. Also what seems interesting that once the -gseparate-dwarf is used, there is no more sourceMappingURL section in the .wasm file.

I could not find any sources of the Chrome DevTools WebAssembly Extension so I can't judge what exactly fails, but I am puzzled about the wasm:// vs file:// schema change between the two scenarios. Can anyone please give some guidance?

[rubu]

Sorry, somehow because of a browser glitch I created two similar issues, closing this since it is a duplicate of 13124