A little howto for getting the wasm/DWARF debugger working in Chrome

[antifuchs]

I was a little frustrated with getting useful debug information in my browser (Arc, Chrome-based) for my wasm app, and took an afternoon to figure something out. This here has worked for me: I get breakpoints, source location, really workable debugging. The info about Source Maps on the Yew page isn't super up to date anymore (the rust WASM working group has stopped updating their book 5 years ago, and in the meantime DWARF has gained quite some nice support).

So here's what I ended up doing (in Chrome):

1. You need to explicitly configure the rust wasm app with data-keep-debug="true" in your app's index.html. I have other directives in there (to disable optimization, for one), but this is the major one that adds DWARF debuginfo to the WASM file that your browser sees. You can check that by copying the link and using wasm-tools' objdump (see below).
2. Install the chrome extension for C/C++ DevTools support and restart chrome. Somehow this extension won't work like all other chrome extensions that only require a reload of the page.
3. When you load your app and the message [C/C++ DevTools Support (DWARF)] Loaded debug symbols for http://[...]/_bg.wasm, found 912 source file(s) appears in the console, you're in business.
4. Use the stepper, enjoy source locations and other cool tools, all thanks to DWARF in wasm!

I'd love to get this into docs somewhere, ideally in Trunk itself.

Also, it appears that the "rust" asset docs about data-keep-debug are a bit misleading. That it says "...even in release mode" made me think that debug info would be included in a dev build - that is not so! You must manually enable this setting, otherwise even a dev build won't have the information.

Hope this will be helpful for others,

Checking that your .wasm file contains DWARF debuginfo

I'm using wasm-tools for that:

console session with my copy-pasted _bg.wasm source file

:;    curl http://127.0.0.1:8080/lz-ui-8ad9021955e51461_bg.wasm | wasm-tools objdump  -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 44.3M  100 44.3M    0     0  1527M      0 --:--:-- --:--:-- --:--:-- 1585M
  types                                  |        0xb -      0x261 |       598 bytes | 79 count
  imports                                |      0x264 -     0x1cff |      6811 bytes | 184 count
  functions                              |     0x1d03 -     0x6f6a |     21095 bytes | 21092 count
  tables                                 |     0x6f6c -     0x6f73 |         7 bytes | 1 count
  memories                               |     0x6f75 -     0x6f78 |         3 bytes | 1 count
  globals                                |     0x6f7a -     0x6f83 |         9 bytes | 1 count
  exports                                |     0x6f86 -     0x73b4 |      1070 bytes | 26 count
  elements                               |     0x73b7 -     0x8850 |      5273 bytes | 4 count
  code                                   |     0x8855 -   0x5c12f0 |   5999259 bytes | 21092 count
  data                                   |   0x5c12f4 -   0x62ebf7 |    448771 bytes | 2 count
  custom "name"                          |   0x62ec00 -   0x800fd1 |   1909713 bytes | 1 count
  custom "producers"                     |   0x800fdd -   0x80104e |       113 bytes | 1 count
  custom ".debug_abbrev"                 |   0x801060 -   0x844424 |    275396 bytes | 1 count
  custom ".debug_str"                    |   0x844434 -  0x1919ea9 |  17652341 bytes | 1 count
  custom ".debug_line_str"               |  0x1919ebb -  0x1919ebb |         0 bytes | 1 count
  custom ".debug_line"                   |  0x1919ecc -  0x1b38983 |   2222775 bytes | 1 count
  custom ".debug_ranges"                 |  0x1b38995 -  0x1bb6715 |    515456 bytes | 1 count
  custom ".debug_rnglists"               |  0x1bb6727 -  0x1bb6727 |         0 bytes | 1 count
  custom ".debug_loc"                    |  0x1bb6735 -  0x1bba002 |     14541 bytes | 1 count
  custom ".debug_loclists"               |  0x1bba014 -  0x1bba014 |         0 bytes | 1 count
  custom ".debug_info"                   |  0x1bba025 -  0x2c658d8 |  17479859 bytes | 1 count
  custom ".debug_frame"                  |  0x2c658e7 -  0x2c658e7 |         0 bytes | 1 count
  custom ".eh_frame"                     |  0x2c658f3 -  0x2c658f3 |         0 bytes | 1 count
  custom "target_features"               |  0x2c65905 -  0x2c6592a |        37 bytes | 1 count

You're looking for the custom ".debug_ sections; if these are present (and probably large), your app has debug info.

[ctron]

Thanks for writing this up! I think there should be more, better, better structured docs for trunk. And I personally think that the homepage approach no longer scales. It's good for a simple: getting started approach, but there could be more.

That's why I started working on a "guide" approach. And I think what you wrote up would be a perfect candidate for that. You can see the current version here: https://trunkrs.dev/guide/ … and the source for that here: https://github.com/trunk-rs/trunk/tree/main/guide

I would love to get some more feedback on the approach, before fully committing to it. However, I also don't see much alternatives (other than different tooling).

However, I think having your findings documented in that guide, actually provide one more reason to go into that direction. And as so far I didn't get any negative feedback, I would encourage you to start a section in that book related to "debugging". That would be super valuable IMHO.