Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One of the pain points to using Wasm in the real world, is the lack of decent debugging.

eg no ability to run code in a debugger, set breakpoints, etc.

That being said, it's an area being worked on.

Wasm generated by LLVM can already have debugging info stored in it using Wasm "custom sections" (they're a thing) in DWARF format. eg .debug_info, .debug_str, (etc)

So, debuggers are at least possible.

Unfortunately, the way Wasm does variables doesn't map to the way DWARF currently does them. So they can't be encoded correctly. A Major problem. :(

Yury Delendik is working through a spec for fixing that (officially):

https://yurydelendik.github.io/webassembly-dwarf/

His initial implementation, with patches (on an older) LLVM so it generates correct debug info according to the in-development spec, is here:

https://github.com/yurydelendik/llvm-project/tree/frame-poin...

Testing and feedback by a wider audience would be useful. :)

A more recent fork of LLVM (based on 8.0.1 dev ~3 days ago), with Yury's patches applied is here:

https://github.com/justinclift/llvm/commits/release_80-wasm_...

Personally, I'm still trying to get my head around generating DWARF debugging info. Hopefully work it out in a few days. :)



Does WebAssembly have a debug trap?


Not specifically:

https://webassembly.github.io/spec/core/syntax/instructions....

There is an "unreachable" which may be possible to use with some creativity.

Haven't really thought that through, as I'm taking a different approach.

Since the Wasm VM executes instructions virtually, it should be feasible to pass the VM a list of addresses to break on.

eg have the VM listen on a socket, and pass it break point info (etc) out of band.

The main Go debugger - Delve - does this with non-Wasm targets.

As a Wasm VM executes, it just needs to check if the current instruction matches the current break point list or any other trigger conditions.

Thus, trying to figure out debug info decoding. At least the location in memory of variables, for displaying them when a breakpoint is hit.

There's not much use in a debugger that can't show the value of variables. ;)


> There's not much use in a debugger that can't show the value of variables. ;)

Well, that depends :)


Heh Heh Heh. While writing that, figured someone might have a valid use case. ;)

What sprang to mind for you?


Nothing specific, just pointing out that debug symbols are not necessary to find value from a debugger. A disassembly and registers (or stack, in this case?) view, along with a place to run debugger commands, is very useful in and of itself.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: