Local variable names lost while debugging

[letmaik]

Local variables appear as var0, var1, etc. in the debugger (Chrome).

[MaxGraey]

That's expected. Unfortunately browsers can't do this. WebAssembly has proposal which should fix this:
https://github.com/WebAssembly/extended-name-section/blob/master/proposals/extended-name-section/Overview.md

Or we still need wait when browsers began support DWARF sections.

[letmaik]

Hm, Chrome and Firefox support DWARF, and binaryen seems to have support for it (WebAssembly/binaryen#2400). Is this a limitation of binaryen then? Or could it be that asc doesn't enable DWARF output in binaryen?

[letmaik]

See also emscripten-core/emscripten#8934 (comment).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[refactorTractor]

If you'll pardon me, I would like this issue reopened. I'm really interested in debugging a wasm module compiled with asc in a runtime other than the browser, like wasmtime. It's not clear to me whether asc emits DWARF info then? So would it be debuggable with gdb or lldb? @MaxGraey any thoughts?

[MaxGraey]

AssemblyScript doesn't emit DWARF yet. Actually it should provide by Binaryen which has some limited support of DWARF but only for transform DWARF debug info and also in very limit way (many optimization passes doesn't handle dwarf data and turned off when dwarf section present). So, first of all, we need to ensure the full support of DWARF for Binaryen

[saulecabrera]

@MaxGraey do the optimization passes that are turned off for DWARF, actually prevent us from exploring this avenue at all? This comment actually hints the opposite of what you're suggesting, so I wonder if it's worth it giving this a try and if it works maybe adding DWARF support as experimental to the compiler.

One of the main reasons why I think that having support for debug symbols is important is because observability and debugging of WASM modules in large, server-side systems is not feasible. Ideally, we could take advantage of the DWARF support in FF/Chrome and build tools to allow developers to debug their modules locally, which would give them an extra layer of confidence when testing their modules.

The other option is to stick with source maps, which are definitely better than dealing with raw traps.

@dcodeIO I'm curious to know what's your take on this.

[dcodeIO]

Generating a DWARF section is definitely something I'd like to explore but don't know when I'll get to it. Information I have from the Binaryen side of things is that, in the current state, Binaryen only implements the pieces of DWARF that are relevant to pipe it through, and it may not be feasible to add a Binaryen API to more conveniently generate DWARF yet, so if we want that we'd need to generate a "line table" (that one was mentioned) etc. on our own and attach the debug section with BinaryenAddCustomSection.

A little less sophisticated alternative that may be a good start however may be to utilize Binaryen's C API to set local names (that is available already but we don't use it yet), which I so far attempted but found that

1. ASC often uses shared locals anyway (unless declared with var), so it is only useful to some extent
2. Binaryen's optimization passes seem to confuse local names, leading to wrong ordering, which we'd have to fix unless we only do it in debug builds where we don't run any optimizations
3. Not all consumers process local names (not sure if browsers do already)

Help appreciated :)

[MaxGraey]

This comment actually hints the opposite of what you're suggesting, so I wonder if it's worth it giving this a try and if it works maybe adding DWARF support as experimental to the compiler.

Check source code for optimization pipeline:
https://github.com/WebAssembly/binaryen/blob/main/src/passes/pass.cpp#L394

As you can see all passes have addIfNoDWARFIssues name due to many passes don't preserve some debug data properly

[saulecabrera]

Thanks for the detailed explanation @dcodeIO. And apologies @MaxGraey I misunderstood your comment.

Just to clarify a bit my point, yeah I only meant exploring this for debug builds. For optimized builds, at least for our use case (which might not be everyone's use case 🤷‍♂️) would be a bit trickier, I don't think that we want debug symbols in optimized modules. If we ever do that, we'll probably want the symbols detached from the module.

In any case, thanks for the pointers, I think this summarizes the state of DWARF support pretty well.

[refactorTractor]

Do you think this is something that would be happening in the "near future" like within a year, or something that is more than a year down the road? @dcodeIO maybe you could share your feelings on that?

[MaxGraey]

I guess this issue should be fixed in 0.21.x with this #2437