DWARF debugging question with clang

[Benjamin Golinvaux]

Hello

In this Chrome announcement where support for DWARF is introduced (https://developers.google.com/web/updates/2019/12/webassembly), I can see this at the end of the page : 

"There is still quite a bit of work to do though. For example, on the tooling side, Emscripten (Binaryen) and wasm-pack (wasm-bindgen) don’t support updating DWARF information on transformations they perform yet. For now, they won’t benefit from this integration."

However, am I correct in assuming that if I use clang directly and don't use binding generation, binaryen is not used and that my binaries should contain DWARF debug info? Maybe the Chrome team is referring to the previous backend? 

(I'd very much like to be able to debug my native code that sometimes behaves differently in wasm than it does in the native project I am using for debugging purposes :)  

Thanks in advance

Benjamin

[Alon Zakai]

1. Yes, if you just use clang, then it can emit DWARF, and that will be valid, if you don't yourself manually run another tool after clang.

2. However, as of last night there *is* support for DWARF in binaryen, so using emscripten will work, at least in debug builds (binaryen will update the DWARF in every optimization it performs). Only in a tip of tree build for now (emsdk install tot).

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/46e7c6de-57f6-4cc1-a0b9-6f29dd785ce2%40googlegroups.com.

[Derek Schuff]

For now you also need to use the temporary flag -gforce_dwarf to actually get the dwarf output. Beware that you are on the bleeding edge if you do this. The Chrome devtools debugger is still missing things like inspecting variable values as well. Eventually that flag will go away and we'll have some reasonable behavior for the regular -g flag and a couple of related flags. 

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQtZ1xM56%2BSN1dtnNBvB%2B3vyWQwXkTO%2B84ubtPmZmb1Kw%40mail.gmail.com.

[Benjamin Golinvaux]

Thanks for your explanations.

I am not really familiar with how tools are interconnected and I thought that binaryen was only used in the fastcomp backend.

"binaryen will update the DWARF in every optimization it performs" : great!   It must have been quite complex to do correctly. Thanks for this!!!

[Alon Zakai]

On Thu, Jan 30, 2020 at 2:41 AM Benjamin Golinvaux <b...@osimis.io> wrote:

Thanks for your explanations.

I am not really familiar with how tools are interconnected and I thought that binaryen was only used in the fastcomp backend.

Ah, just to clarify, it is used to optimize in both backends (reduces production build sizes by around 20%).

In fastcomp it was also used for asm2wasm, though, which is not relevant in the new backend.

 

"binaryen will update the DWARF in every optimization it performs" : great!   It must have been quite complex to do correctly. Thanks for this!!!

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/fa8243c5-6f94-4cb1-92f0-ee9cb5cc18e4%40googlegroups.com.

[Benjamin Golinvaux]

"Beware that you are on the bleeding edge if you do this."

Is it somehow possible to disable the binaryen transformations in the debug builds, so that I do not need to switch to bleeding edge and can use Dwarf in my production-tested version?   Is this -gforce_dwarf flag only used in these binaryen transformations ?

Thank you.

[Walt Tucker]

Are there any gotchas or extra flags needed when using tot and -gforce_dwarf? I think I've been able to build with dwarf info (at least the wasm has custom .debug_* headers when viewing with wasm-objdump), yet when in chrome/firefox I don't see my c source files available for debugging. Is this not enabled with the llvm-wasm backend, similar to emscripten .wat output?

On Wednesday, January 29, 2020 at 6:35:45 PM UTC-5, Derek Schuff wrote:

For now you also need to use the temporary flag -gforce_dwarf to actually get the dwarf output. Beware that you are on the bleeding edge if you do this. The Chrome devtools debugger is still missing things like inspecting variable values as well. Eventually that flag will go away and we'll have some reasonable behavior for the regular -g flag and a couple of related flags. 

On Wed, Jan 29, 2020 at 3:21 PM Alon Zakai <alon...@gmail.com> wrote:

1. Yes, if you just use clang, then it can emit DWARF, and that will be valid, if you don't yourself manually run another tool after clang.

2. However, as of last night there *is* support for DWARF in binaryen, so using emscripten will work, at least in debug builds (binaryen will update the DWARF in every optimization it performs). Only in a tip of tree build for now (emsdk install tot).

--
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.

[Alon Zakai]

On Thu, Jan 30, 2020 at 11:38 PM Benjamin Golinvaux <b...@osimis.io> wrote:

"Beware that you are on the bleeding edge if you do this."

Is it somehow possible to disable the binaryen transformations in the debug builds,

You can link with -O0, which will prevent optimizations at link time, including binaryen. I'm proposing we improve this in

https://github.com/emscripten-core/emscripten/issues/10325

so that I do not need to switch to bleeding edge and can use Dwarf in my production-tested version?   Is this -gforce_dwarf flag only used in these binaryen transformations ?

-gforce_dwarf is an emscripten flag that makes it tell both LLVM and Binaryen to emit DWARF and update it. Currently if you want DWARF you need that flag, but see that link above, I'd like to remove it and make this all simpler.

It might be worth waiting for that proposal before starting to use -gforce_dwarf, hopefully it will happen very soon.

Thank you.

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/8239c297-3264-49ac-8552-9e02652ee241%40googlegroups.com.

[Alon Zakai]

On Fri, Jan 31, 2020 at 8:41 AM Walt Tucker <tucke...@gmail.com> wrote:

Are there any gotchas or extra flags needed when using tot and -gforce_dwarf? I think I've been able to build with dwarf info (at least the wasm has custom .debug_* headers when viewing with wasm-objdump), yet when in chrome/firefox I don't see my c source files available for debugging. Is this not enabled with the llvm-wasm backend, similar to emscripten .wat output?

It should just work, but it does need a very new Chrome, in the dev channel (not stable or even beta). I believe Firefox lacks DWARF support currently, so that's not an option.

There are a few other potential gotchas here, as this is bleeding edge, like if you build with an absolute path (emcc /home/username/../foo.cpp) vs relative (emcc foo.cpp), as the devtools used to care about the difference, but that might be fixed by now.

This is quite new and still a work in progress - when it's more stable and useful we'll probably have a blogpost out etc. and announce that.

- Alon

On Wednesday, January 29, 2020 at 6:35:45 PM UTC-5, Derek Schuff wrote:

For now you also need to use the temporary flag -gforce_dwarf to actually get the dwarf output. Beware that you are on the bleeding edge if you do this. The Chrome devtools debugger is still missing things like inspecting variable values as well. Eventually that flag will go away and we'll have some reasonable behavior for the regular -g flag and a couple of related flags. 

On Wed, Jan 29, 2020 at 3:21 PM Alon Zakai <alon...@gmail.com> wrote:

1. Yes, if you just use clang, then it can emit DWARF, and that will be valid, if you don't yourself manually run another tool after clang.

2. However, as of last night there *is* support for DWARF in binaryen, so using emscripten will work, at least in debug builds (binaryen will update the DWARF in every optimization it performs). Only in a tip of tree build for now (emsdk install tot).

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpQtZ1xM56%2BSN1dtnNBvB%2B3vyWQwXkTO%2B84ubtPmZmb1Kw%40mail.gmail.com.

--

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/1156b20b-c2c2-4563-932a-a6be8779ec66%40googlegroups.com.

[Walt Tucker]

On Friday, January 31, 2020 at 4:30:16 PM UTC-5, Alon Zakai wrote:

It should just work, but it does need a very new Chrome, in the dev channel (not stable or even beta). I believe Firefox lacks DWARF support currently, so that's not an option.

There are a few other potential gotchas here, as this is bleeding edge, like if you build with an absolute path (emcc /home/username/../foo.cpp) vs relative (emcc foo.cpp), as the devtools used to care about the difference, but that might be fixed by now.

This is quite new and still a work in progress - when it's more stable and useful we'll probably have a blogpost out etc. and announce that.

- Alon

Thanks, it must have been since I was on the official stable Chrome. I'll try that out.

Is DWARF the end goal for source-level debugging of wasm? I'm hoping it ends up being more stable than the current source maps solution, which has been near unusable for us. (with massive codebase/binary size) 

[Alon Zakai]

Yes, DWARF is the plan. Source maps are not enough, and instead of inventing something new the wasm community is focusing on DWARF support in the tools and VMs.

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/4a0c17b2-64c8-4796-bf18-dfd2bb649849%40googlegroups.com.