Debugging WASM with C++ source

[cecl...@hotmail.com]

This page says that you can debug C++ source code when running WASM in Chrome/Firefox/Safari:
https://emscripten.org/docs/porting/Debugging.html

Are there any details on how to make this work?  Thank you so much

[cecl...@hotmail.com]

Also, sorry, I should clarify, I have set the compiler options as instructed on that page, in Chrome I get errors, but no C++ source code.  In the sources tree, no C++ files appear.  There's a message: "Source map detected.  Associated files should be added to the file tree.  You can debug these resolved source files as regular JavaScript files.  Associated files are available via file tree or Ctrl + P"

Ctrl + P doesn't bring up any C++ files, I'm not sure what to do.

Thanks so much

[Floh]

Apologies for not having a helpful answer, but I also never got WASM source map debugging to work in any browser. I had it working with asm.js, but even that wasn't very useful either because the source-map debug information only provides line- and global-symbol-mapping, local variable names were not mapped. It also broke down fairly quickly for slightly bigger projects (debugger becoming unresponsive etc...).

My debugging strategy is basically to always be able to create a native build from the same source (which assumes that most of the code is not platform-specific), and debug this in Xcode, VSCode or Visual-Studio-proper. Bugs seem to map pretty well between native code and WASM, at least it's a long time since I have seen asm.js or WASM specific problems, but this may also be because I have subconsciously adjusted my coding style to avoid some dark corners ;)

For things that can't be debugged that way: good old printf-debugging, and the various runtime debug helpers emscripten offers (like ASSERTIONS and SAFE_HEAP), but it's a long time since I had to use those.

A proper debugging extension for VSCode would be nice though (VSCode has plugin support specifically for custom debuggers).

[Alon Zakai]

The Ctrl+P stuff is new, but it should work. For example,

./emcc tests/hello_world.c -g4 -o a.html

python -m SimpleHTTPServer

browse to localhost:8000/a.html in chrome

go to sources, ctrl-p, pick hello_world.c

Then it shows up, breakpoints work, etc.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Floh]

Hmm, indeed. It works immediately when the source files are in the same directory as the build result. It even automatically lists the .c file...

I can't get it to work with "out-of-source builds" yet. I figured out that I need to tell Chrome the source code directory via "Filesystem -> Add to workspace...",

and then I can open the source files with Ctrl-P, but it doesn't recognize the breakpoints (I can set them, but they're not hit).

I'll do some more experiments. Maybe the source file isn't properly matched with the 'reference' from the WASM file.

Cheers!

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Floh]

Ok, I got it working (somewhat) with a cmake project.

First problem I had was an oversight, I didn't pass -g4 to the linker stage too.

After that one can look into the .wasm.map files that have been created, and confirm that the source file paths are in there.

Then run the program in Chrome, open the devtool, go to the source panel *and hit refresh*. After that a tree-item is listed next to the .html and .js file, opening this shows all the sources.

But clicking on those source files only results in an empty tab, no source files are actually loaded. Looking at the webserver log reveals that the browsers tries to load those source files via HTTP, which doesn't work, because the source files are somewhere else in the filesystem.

That's where the Filesystem tab in the devtools come in, adding the 'lowest common parent directory' under which all sources are located seems to work, Chrome seems to properly map the absolute source paths from the .wasm.map files.

Now loading the source and breakpoints work, but the actual debugging experience isn't much better then what I remember from a few years ago. Even for minimal programs like my sokol-samples stepping through the code is very 'laggy', the laptop is running hot and goes into jet-mode for some reason, sometimes I need to 'step' ten times on a single line of code until progressing to the next line, sometimes I'm ending up in a completely wrong location when stepping into a new source file, and local variable names are not mapped to their C/C++ names (they only show up as "arg#0, local#1, local#2...".

Compared to a "native" debugging experience this isn't much to write home about unfortunately ;)

[Brian Gavin]

My experience with source maps is similar to Floh.   Kind of works for very simple hello world apps but even then there are some lines I can not set breakpoints.  No variable inspection.   Stepping into and out of functions does not always work.   

Unfortunately my debugging technique is lots of prints and dump callstack.   You need to plan for development time to take longer then a regular C++ application.

Better debugging is my number 1 feature wish.

Brian Gavin

[Александр Гурьянов]

Agree, I never debug emscripten output. Source map never works for big
code bases. So all bug fixing done by playing with C++ native build,
in hope that it will be ported 1:1, actually it's almost true.

пт, 5 апр. 2019 г. в 03:28, Brian Gavin <bgav...@gmail.com>:

[Alon Zakai]

Yeah, debugging is definitely one of the bigger missing pieces here. This will hopefully improve soon in toolchains and browsers, there is ongoing work on it. Meanwhile debugging a parallel native build is often best, as mentioned.

[Charles Vaughn]

At Tableau, what we've done is very similar to what Floh mentioned, but baked into our tooling. It's probably not for everyone, since we require calls into WASM be asynchronous, and Javascript access WASM's heap in a serializable way. From those restrictions, we're able to use a python server that loads a native version of our WASM, and exposes our methods via a REST interface. We even support native executing Javascript through Chrome's remote debugging protocol.

If there's interest keeping in mind those restrictions, I can look into sharing source.

On Friday, April 5, 2019 at 1:28:58 PM UTC-7, Alon Zakai wrote:

Yeah, debugging is definitely one of the bigger missing pieces here. This will hopefully improve soon in toolchains and browsers, there is ongoing work on it. Meanwhile debugging a parallel native build is often best, as mentioned.

On Thu, Apr 4, 2019 at 8:56 PM Александр Гурьянов <caii...@gmail.com> wrote:

Agree, I never debug emscripten output. Source map never works for big
code bases. So all bug fixing done by playing with C++ native build,
in hope that it will be ported 1:1, actually it's almost true.

пт, 5 апр. 2019 г. в 03:28, Brian Gavin <bgav...@gmail.com>:
>
> My experience with source maps is similar to Floh.   Kind of works for very simple hello world apps but even then there are some lines I can not set breakpoints.  No variable inspection.   Stepping into and out of functions does not always work.
>
> Unfortunately my debugging technique is lots of prints and dump callstack.   You need to plan for development time to take longer then a regular C++ application.
>
> Better debugging is my number 1 feature wish.
>
> Brian Gavin
>
> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Beuc]

I'm interested :)

- Beuc

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.

[Александр Гурьянов]

+1

пт, 12 апр. 2019 г. в 01:36, Beuc <be...@beuc.net>:

>
> I'm interested :)
>
> - Beuc
>
> On 11/04/2019 20:15, Charles Vaughn wrote:
>
> At Tableau, what we've done is very similar to what Floh mentioned, but baked into our tooling. It's probably not for everyone, since we require calls into WASM be asynchronous, and Javascript access WASM's heap in a serializable way. From those restrictions, we're able to use a python server that loads a native version of our WASM, and exposes our methods via a REST interface. We even support native executing Javascript through Chrome's remote debugging protocol.
>
> If there's interest keeping in mind those restrictions, I can look into sharing source.
>
> On Friday, April 5, 2019 at 1:28:58 PM UTC-7, Alon Zakai wrote:
>>
>> Yeah, debugging is definitely one of the bigger missing pieces here. This will hopefully improve soon in toolchains and browsers, there is ongoing work on it. Meanwhile debugging a parallel native build is often best, as mentioned.
>>
>> On Thu, Apr 4, 2019 at 8:56 PM Александр Гурьянов <caii...@gmail.com> wrote:
>>>
>>> Agree, I never debug emscripten output. Source map never works for big
>>> code bases. So all bug fixing done by playing with C++ native build,
>>> in hope that it will be ported 1:1, actually it's almost true.
>>>
>>> пт, 5 апр. 2019 г. в 03:28, Brian Gavin <bgav...@gmail.com>:
>>> >
>>> > My experience with source maps is similar to Floh. Kind of works for very simple hello world apps but even then there are some lines I can not set breakpoints. No variable inspection. Stepping into and out of functions does not always work.
>>> >
>>> > Unfortunately my debugging technique is lots of prints and dump callstack. You need to plan for development time to take longer then a regular C++ application.
>>> >
>>> > Better debugging is my number 1 feature wish.
>>> >
>>> > Brian Gavin
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

[Robert Aboukhalil]

Also interested!

On Thursday, April 11, 2019 at 7:44:15 PM UTC-7, caiiiycuk wrote:

+1

пт, 12 апр. 2019 г. в 01:36, Beuc <be...@beuc.net>:
>
> I'm interested :)
>
> - Beuc
>
> On 11/04/2019 20:15, Charles Vaughn wrote:
>
> At Tableau, what we've done is very similar to what Floh mentioned, but baked into our tooling. It's probably not for everyone, since we require calls into WASM be asynchronous, and Javascript access WASM's heap in a serializable way. From those restrictions, we're able to use a python server that loads a native version of our WASM, and exposes our methods via a REST interface. We even support native executing Javascript through Chrome's remote debugging protocol.
>
> If there's interest keeping in mind those restrictions, I can look into sharing source.
>
> On Friday, April 5, 2019 at 1:28:58 PM UTC-7, Alon Zakai wrote:
>>
>> Yeah, debugging is definitely one of the bigger missing pieces here. This will hopefully improve soon in toolchains and browsers, there is ongoing work on it. Meanwhile debugging a parallel native build is often best, as mentioned.
>>
>> On Thu, Apr 4, 2019 at 8:56 PM Александр Гурьянов <caii...@gmail.com> wrote:
>>>
>>> Agree, I never debug emscripten output. Source map never works for big
>>> code bases. So all bug fixing done by playing with C++ native build,
>>> in hope that it will be ported 1:1, actually it's almost true.
>>>
>>> пт, 5 апр. 2019 г. в 03:28, Brian Gavin <bgav...@gmail.com>:
>>> >
>>> > My experience with source maps is similar to Floh.   Kind of works for very simple hello world apps but even then there are some lines I can not set breakpoints.  No variable inspection.   Stepping into and out of functions does not always work.
>>> >
>>> > Unfortunately my debugging technique is lots of prints and dump callstack.   You need to plan for development time to take longer then a regular C++ application.
>>> >
>>> > Better debugging is my number 1 feature wish.
>>> >
>>> > Brian Gavin
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

>>> > To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.

[Wanghb Wang]

interested +1

is there any update?
在 2019年3月31日星期日 UTC+8下午1:31:28，Cooper Clauson写道：

[Benjamin Golinvaux]

I would be very interested, too! 

[Phil Moc]

Literally months late, but I'm also interested.

I also noticed another issue with using -g4.  It appears the source-map does not take into account the output directory.  That is, if I output the build results somewhere other than where I ran the build command, the source paths seem to become invalid. 

So this works:

./emcc tests/hello_world.c -g4 -o a.html --source-map-base file:///(path_to_emsdk)/emscripten/1.38.13/

However, in my experience this would not:

mkdir build_results

./emcc tests/hello_world.c -g4 -o build_results/a.html  --source-map-base file:///(path_to_emsdk)/emscripten/1.38.13/build_results/

There might be a very simple extra flag I could add to fix this that I'm not aware of.  Also, this --source-map-base flag seems necessary for the browser to find the map (whether you're on localhost or just using file:///) despite it having not apparently been mentioned in here.