0

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?

Attaching screenshots from both cases to illustrate the schema differences: Bad Example Good Example

Rudolfs Bundulis
  • 11,636
  • 6
  • 33
  • 71

1 Answers1

0

I had similar problems whilst trying to debug bigger project using webpack and with whole environment set with Docker.

First thing is that dwarf based debug is mutually exclusive with js source maps. wasm-opt is stripping dwarf if using other flag than -g or -g3 (at least it was true with emsdk 2.0.10)

Since we are building in Docker start of absolute path to sources has been different to absolute path on host PC where source lays thus wrong file:// to workaround this issue I have changed dwarf paths by compiler and linker option

-ffile-prefix-map=/prefix/dir/from/docker=/absolute/path/to/src

Then I could set break in sources found in files:// (and see debug information like local variables in C/C++ manner).

I am using also EM_ASM(debugger;); to break on demand.

One thing which was not working at that time was std:string showing incorrectly nulled value.

Ryszard Grzesica
  • 176
  • 6