Any plan to support to debug Webassembly file?

Subprojects LLDB
1

Hi there,

I am working on a project which involves compiling C++ source file to Webassembly byte code file with LLVM. The LLVM works well and can generate wasm byte code file with DWARF debug sections like .debug_line. I can run the generated wasm file with my wasm virtual machine. However I find LLDB doesn’t support debugging wasm file. Do we have plan to enable LLDB debugging wasm file? Thanks for any information.

BR,
Terry

2

I’m not sure I understand what the question is. Do you want that LLDB attachs to the wasm program running inside your VM and then debug the wasm program via LLDB? Or that LLDB can run the wasm module itself like an executable and then run it/step through it/inspect it/etc.?

Cheers,
- Raphael

3

+lldb-dev

4

Hi Raphael,

Thanks for your recommendation. How about the very first step which
enables LLDB to recognize the wasm bytecode via commands like "lldb
my.wasm" or "file my.wasm" inside lldb? And IMHO the second step is to
enable LLDB to recognize the dwarf sections embedded in wasm bytecode
file. Do you have any suggestion where to start? I searched around and
couldn't find useful instructions/documentations for above two steps.

BR,
Terry

5

You would need to implement an ObjectFile and SymbolFile plugin for your .wasm files for lldb to make a Target for them.

Jim

6

Hi Jim,

Thanks for your help. I implemented a WASM file plugin under folder Plugins/ObjectFile/WASM. Now the LLDB can make a target for .wasm file. My .wasm file is built with clang and -g option. It does contain dwarf informations spreaded in a series of .debug_xx sections. However I failed to set breakpoint against a function name:

(lldb) target create “/home/projects/zz.wasm”
Current executable set to ‘/home/projects/zz.wasm’ (wasm32).
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.

Is this related to Symtab? Currently I left function “Symtab *ObjectFileWASM::GetSymtab()” as empty function because the .wasm file doesn’t include one. Or should I make LLDB to utilize the .debug_line information? I couldn’t figure out which information should be used to enable LLDB to correctly set the breakpoint. Thanks in advance.

BR,
Terry

7

Hi Jim,

Thanks for your help. I implemented a WASM file plugin under folder Plugins/ObjectFile/WASM. Now the LLDB can make a target for .wasm file. My .wasm file is built with clang and -g option. It does contain dwarf informations spreaded in a series of .debug_xx sections. However I failed to set breakpoint against a function name:

(lldb) target create “/home/projects/zz.wasm”
Current executable set to ‘/home/projects/zz.wasm’ (wasm32).
(lldb) b main
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.

Is this related to Symtab? Currently I left function “Symtab *ObjectFileWASM::GetSymtab()” as empty function because the .wasm file doesn’t include one. Or should I make LLDB to utilize the .debug_line information? I couldn’t figure out which information should be used to enable LLDB to correctly set the breakpoint. Thanks in advance.

The ObjectFile subclasses are asked to create sections with the virtual:

virtual void ObjectFile::CreateSections(SectionList &unified_section_list) = 0;

In this function you must correctly create sections and give them appropriate lldb::SectionType enum values. For “.debug_info”, this should be eSectionTypeDWARFDebugInfo. There are many others. Check out the other ObjectFile subclasses like ObjectFilePECOFF::CreateSections() to see how they do this. Many object files have different naming mechanisms and restrictions (mach-o can only have 16 character section names in ObjectFileMachO), so we leave the conversion of section types to each ObjectFile since they can use flags, section names, and more to determine what kind of sections are available from their specific object file. Code that uses DWARF will ask for a section using lldb::SectionType values. If you fix this, the DWARF should be found and parsed and you might be able to set a breakpoint. We also do this to avoid code having to ask for sections by name, and then retry all sorts of different section names (“.debug_info” for most, then fall back to “__debug_info” for mach-o, and add more for different object files in the future). This keeps the code that needs to access DWARF cleaner.

Greg

8

Got it and Thanks Greg.

BR,
Terry