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

Optionally generate DWARF debugging info for Wasm files #4

Open
dicej opened this issue Nov 3, 2022 · 5 comments
Open

Optionally generate DWARF debugging info for Wasm files #4

dicej opened this issue Nov 3, 2022 · 5 comments

Comments

@dicej
Copy link
Collaborator

dicej commented Nov 3, 2022

This would make debugging using e.g. wasmtime and gdb much more useful. To start with, just having line numbers would be a big win. Local variable info would be great, also.

@konsoletyper
Copy link

I implemented this feature in main repository. I saved .debug_X sections to binary file, added them to ELF file and used different verifiers (dwarfdump, objdump, llvm-dwarfdump) to check that the info is correct. However, nothing happens in Chrome devtools with enabled DWARF support and in wasmtime, they just silently ignore debug info without any errors. Do you have any clues how to debug wasmtime and Chrome devtools in order to understand, what they also need to enable debugging?

@dicej
Copy link
Collaborator Author

dicej commented Nov 19, 2022

Thanks for working on this! I don't have any relevant experience with this, but I have a couple of suggestions:

  • Have you verified that Chrome devtools and Wasmtime recognize the debug symbols in LLVM-produced (e.g. rustc or clang) modules? If LLVM modules work, then it might be worth studying the WAT form of those modules to see what's different about them vs. what TeaVM is doing.
  • You could also study the Wasmtime source code and possibly add extra logging to it. Specifically, I'd recommend looking at how the ModuleTranslation::debuginfo field is populated.

@konsoletyper
Copy link

Have you verified that Chrome devtools and Wasmtime recognize the debug symbols in LLVM-produced (e.g. rustc or clang) modules? If LLVM modules work, then it might be worth studying the WAT form of those modules to see what's different about them vs. what TeaVM is doing.

Sure I did. Of course, there are many differences, there's too much information I need to understand and too much functionality to implement. I believe, the basic things are similar. At least, as far as I understand.

You could also study the Wasmtime source code and possibly add extra logging to it. Specifically, I'd recommend looking at how the ModuleTranslation::debuginfo field is populated.

That's it! I could do everything myself, learn how to use Rust, learn Rust itself, learn how to build wasmtime, how to debug it, learn its source code and find the relevant one, learn how it works and why it rejects TeaVM-related module. OR. Perhaps there's already a Rust/Wasmtime/DWARF hacker who actually contributes to wasmtime, I perhaps you could know one to ask their help. This would save me much time.

@konsoletyper
Copy link

Ok, I found the issue and now something work. gdb shows definitely wrong locations, but at least they point somehwhere not far from original ones. Also, gdb crashes quickly when trying to debug PI calculator. Also, Chrome still does not recognize DWARF. But not we have at least something working, which can further be improved and fixed.

@konsoletyper
Copy link

That's it. Now it finally works. I managed to walk through PI calculator, with some rare glitches like jumping on random line. But in most cases debugger placement was precise. There's still this weird issue with gdb/wasmtime, but only in case I put breakpoint on main method and start walking. I also tried with Ctrl+C during calculation, and in this case gdb works find. lldb does not work for me, just does not display any useful information. Chrome works fine, except for "step over" , which seems to step on every instruction instead of skipping whole line.

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

No branches or pull requests

2 participants