Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wasm: add DWARF sections #33503

Open
walkingeyerobot opened this issue Aug 6, 2019 · 22 comments
Open

wasm: add DWARF sections #33503

walkingeyerobot opened this issue Aug 6, 2019 · 22 comments

Comments

@walkingeyerobot
Copy link

@walkingeyerobot walkingeyerobot commented Aug 6, 2019

What version of Go are you using (go version)?

$ go version
go version go1.12.5 linux/amd64

Output source maps for use with browser developer tools to enable simple step debugging inside browsers. Details of the spec can be found here: https://sourcemaps.info/spec.html

@dmitshur dmitshur changed the title wasm feature request: output source maps wasm: output source maps Aug 6, 2019
@dmitshur dmitshur added this to the Unplanned milestone Aug 6, 2019
@agnivade
Copy link
Contributor

@agnivade agnivade commented Aug 7, 2019

If I am reading the link correctly, it is the spec for JS source maps. Wasm source maps are not part of a specification yet and it is still in progress. Discussion is ongoing here - WebAssembly/design#1051.

@walkingeyerobot
Copy link
Author

@walkingeyerobot walkingeyerobot commented Aug 7, 2019

It's the spec for sourcemaps within browser dev tools, not specific to javascript. Emscripten is already capable of outputting these for c++ compiled to wasm. See their docs at https://emscripten.org/docs/porting/Debugging.html for more detail.

@agnivade
Copy link
Contributor

@agnivade agnivade commented Aug 7, 2019

I see. Thanks.

@torbenschinke
Copy link
Contributor

@torbenschinke torbenschinke commented Jun 2, 2020

Meanwhile Chrome got native dwarf-support for wasm-files, see [1]. It could be a better / simpler alternative to embed debug symbols into the wasm file directly.

Also, one can derive source maps from embedded symbols using tools like [2]. So a dwarf support may be sufficient.

It looks like gc does not embed those symbols currently? Do you have any insights?

[1] https://developers.google.com/web/updates/2019/12/webassembly#enter_dwarf
[2] https://chromium.googlesource.com/external/github.com/kripken/emscripten/+/1.38.11/tools/wasm-sourcemap.py

@jeremyfaller
Copy link
Contributor

@jeremyfaller jeremyfaller commented Jun 2, 2020

The linker explicitly strips DWARF from generated wasm binaries. I would need to about the wasm binary format to add support for DWARF, but it's probably entirely doable to just tweak the linker to spit out DWARF.

@torbenschinke
Copy link
Contributor

@torbenschinke torbenschinke commented Jun 3, 2020

Yury Delendik has summarized his findings in [1] and it looks like each DWARF section has a custom section within the wasm binary, just like it shall be in ELF binaries.

[1]https://yurydelendik.github.io/webassembly-dwarf/

@torbenschinke
Copy link
Contributor

@torbenschinke torbenschinke commented Jun 5, 2020

@jeremyfaller Are you planning to work on adding support for DWARF?

@jeremyfaller
Copy link
Contributor

@jeremyfaller jeremyfaller commented Jun 5, 2020

Yeah, I'll take a look. It won't make 1.15 (that's frozen), but I'll put something together (on master) that can make 1.16.

@jeremyfaller
Copy link
Contributor

@jeremyfaller jeremyfaller commented Sep 1, 2020

This is looking less likely for me to get to for 1.16. I'm being lent over to the COVID exposure notification work. I would be happy to do code reviews for anyone that takes over. For now, I'm un-committing myself to delivering for 1.16.

@haselkern
Copy link

@haselkern haselkern commented Sep 8, 2020

Hi @jeremyfaller! I would be willing to put some time and effort into this. Could you give me a quick rundown of what would need to be done to make this work?

@neelance neelance changed the title wasm: output source maps wasm: add DWARF sections Oct 28, 2020
@haselkern
Copy link

@haselkern haselkern commented Nov 9, 2020

I have extended the compiler to include DWARF symbols in the Wasm-File, and got Chrome to recognize that there are debug symbols available. But it cannot yet load the underlying source code.
grafik

wasm-validate from the wabt project project passes and the .wasm file is executed correctly. However dwarfdump reports error: main.wasm: Invalid data was encountered while parsing the file. So somehow there is something wrong with the binary format in the output file.

Since I'm no expert on this, any pointers in the right direction would be greatly appreciated, though I will continue to look into this. I have attached a zip containing a compiled Wasm-file, if that is a help to anyone.

wasm-dwarf.zip

@thanm
Copy link
Member

@thanm thanm commented Nov 9, 2020

Which dwarf dumper are you using? Is this the one based on https://www.prevanders.net/dwarf.html ?

I would try building and running llvm-dwarfdump instead, that dumper definitely has support for wasm.

@haselkern
Copy link

@haselkern haselkern commented Nov 10, 2020

I'm on a Mac using Apples llvm-dwarfdump and could successfully use that to inspect a Wasm file with debug information generated from Rust code. Thank you for your suggestion though!

@haselkern
Copy link

@haselkern haselkern commented Nov 24, 2020

I'm now at a point where I could use some more help. I had the problem that the .debug_abbrev section was not written correctly, but I have since fixed that. I wrote a small helper program that uses Go's built in dwarf functionality and that is able to correctly (?) print out DWARF information from a Wasm file generated from Rust and also from my modified Go compiler! Unfortunately Chrome still does not pick up the source map and dwarfdump also still reports error: main.wasm: Invalid data was encountered while parsing the file.

I have attached a zip containing my helper program and both Wasm files. You can run go run helper.go -file go.wasm (or rust.wasm) and the helper will print the sections present in the Wasm file and then all DIEs.

If anyone has an idea as to what I might be doing wrong, do not hesitate to contact me!

wasm.zip

@happybeing
Copy link

@happybeing happybeing commented Nov 24, 2020

@nbaksalyar is this something you can help answer?

@RReverser
Copy link

@RReverser RReverser commented Dec 2, 2020

Hi @haselkern! I'm very excited to see DWARF support getting ported to the WebAssembly target.

On the Chrome side, we're currently making some improvements to the WebAssembly debugging, and things are a bit in flux, which might be at least partially responsible for why you're not seeing sources (assuming that DWARF is otherwise valid).

We'll be ready to share more in a week at the ChromeDevSummit as part of the https://developer.chrome.com/devsummit/sessions/debugging-webassembly-with-modern-tools/ session. Perhaps it's worth syncing up after that?

Meanwhile, llvm-dwarfdump should be the easiest tool for verifying that DWARF data is correctly encoded in WebAssembly files. (UPD: and it does look like it fails on your go.wasm)

@RReverser
Copy link

@RReverser RReverser commented Dec 2, 2020

Okay, Rust/Gimli-based dwarfdump gives a lot better output (as usual :P). I'd suggest trying it out for further debugging.

  1. In case you don't have Rust toolchain installed, install it from https://rustup.rs/.
  2. Install Gimli's dwarfdump example with $ cargo install gimli --example dwarfdump.

Here is the output log it produced: out.log

In there, you can see a bunch of "Unable to get header for file [number]" in the DWARF data - looks like files are not properly declared.

Additionally, all (?) the locations like DW_AT_stmt_list, DW_AT_ranges, DW_AT_low_pc, DW_AT_high_pc and DW_AT_type seems to be set to zero (0x00000000).

@RReverser
Copy link

@RReverser RReverser commented Dec 11, 2020

Hi again! We now have released the mentioned new and enhanced DWARF debugging experience for WebAssembly - check out this post about various new features and usage instructions: https://developers.google.com/web/updates/2020/12/webassembly (or check out the short talk here https://youtu.be/VBMHswhun-s instead).

I believe, once issues, described in my previous comment, are addressed and Go emits correct DWARF information, it should mostly work out of the box with Go-emitted Wasm too, but there isn't much I can help with until then.

@gopherbot
Copy link

@gopherbot gopherbot commented Jan 11, 2021

Change https://golang.org/cl/283012 mentions this issue: wasm: include DWARF information in Wasm builds

@haselkern
Copy link

@haselkern haselkern commented Jan 11, 2021

I opened a change request so that other people could look into this. I could not figure out why the locations were all set to zero, considering that this information is written correctly on other architectures. Any ideas on what would need to be changed are very welcome!

@RReverser
Copy link

@RReverser RReverser commented Jan 11, 2021

Any ideas on what would need to be changed are very welcome!

Is it possible you need special handling for Wasm relocations? I'm not too familiar with Go, is there a way to emit object files before relocation & linking is done?

If it is, then you should be able to use dwarfdump tool from above to check whether at least individual objects contain correct debug info.

If they do, then the issue is in the relocation/linker implementation, if they don't, then it's during emitting itself.

@haselkern
Copy link

@haselkern haselkern commented Feb 15, 2021

If anyone can give me a clear direction to what exactly is missing, I would be happy to implement it. But as it is now I will stop working on this, as I have made no meaningful progress in the past few weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants