1365200 - Support Unity game developers to debug Wasm web exports

Status: REOPENED

(DevTools :: Debugger, enhancement, P5)

Description

[Jukka Jylänki]

Attachment: integer_overflow.png

Here is a good test case for needed Wasm debugging support that Unity game developers will need.

STR:

1. Download and unzip http://clb.demon.fi/dump/wasm_development_no_compression.zip
2. Spawn a local web server to run index.html.
3. Play the game and let the avalanche reach the player.

When the game ends, there will be an "Integer overflow" trap coming from WebAssembly code. (see attached image) This is possibly due to a bug that the developer has done in their code, but currently they have no way to debug this.

Marking this bug as a meta placeholder to ensure that these type of errors in Unity applications will become debuggable in Firefox. Namely:

a) when this type of trap occurs, we should have a way to break in the debugger right when the trap is being emitted ("first-chance exception handling" in Visual Studio/.Net parlance) and see where in wasm code it is being emitted from, along with call stacks and being able to examine the wasm variables,

and 

b) currently we get "Unfortunately, this WebAssembly module is too big to view as text. We are working hard to remove this limitation.". I think it would be good to just view the individual functions at a time, and never the whole body of the full Module? That way we would run into issues only if individual functions become too large?

Mapping to original Unity C# and C/C++ source code is beyond this item, we can assume here that the developer is proficient in WebAssembly and has access to the source that they can then mentally map back to.

The exported build is a development build that has function names intact. We can assume it to require a 64-bit browser to debug and that a 32-bit one is not enough, if memory is a concern.

Comment 1

[Luke Wagner [:luke]]

(In reply to Jukka Jylänki from comment #0)
> a) when this type of trap occurs, we should have a way to break in the
> debugger right when the trap is being emitted ("first-chance exception
> handling" in Visual Studio/.Net parlance) and see where in wasm code it is
> being emitted from, along with call stacks and being able to examine the
> wasm variables,

IIUC, that should Just Work via the existing "break on exception" UI and the fact that traps are defined as throwing exceptions.

> b) currently we get "Unfortunately, this WebAssembly module is too big to
> view as text. We are working hard to remove this limitation.". I think it
> would be good to just view the individual functions at a time, and never the
> whole body of the full Module? That way we would run into issues only if
> individual functions become too large?

That's definitely the goal; it just takes some work b/c of the current debugger design.  Yury has some good plans here.

Comment 2

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.