[Lldb-commits] [PATCH] D71575: [LLDB] Add initial support for WebAssembly debugging

[Paolo Severini via Phabricator via lldb-commits]

paolosev created this revision.
paolosev added reviewers: jasonmolenda, clayborg.
paolosev added projects: LLDB, LLVM.
Herald added subscribers: llvm-commits, lldb-commits, sunfish, aheejin, jgravelle-google, sbc100, aprantl, mgorny, dschuff.

Current versions of Clang emit (partial) DWARF debug information in WebAssembly modules and we can leverage this debug information to give LLDB the ability to do source-level debugging of Wasm code that runs in a WebAssembly engine.

A way to do this could be to use the remote debugging functionalities provided by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not only to connect a debugger to a process running on a remote machine, but also to
connect the debugger to a managed VM or script engine that runs locally, provided that the engine implements a GDB-remote stub that offers the ability to access the engine runtime internal state.

To make this work, the GDB-remote protocol would need to be extended with a few Wasm-specific custom query commands, used to access aspects of the Wasm engine state (like the Wasm memory, Wasm local and global variables, and so on).
Furthermore, the DWARF format would need to be enriched with a few Wasm-specific extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf.

This CL only introduces classes ObjectFileWasm, SymbolVendorWasm and DynamicLoaderWasmDYLD as a first step to enable LLDB debugging of WebAssembly targets. In more detail:

- Class **ObjectFileWasm** represents a WebAssembly module loaded in the debuggee process. It knows how to parse Wasm module and store the Code section and the DWARF-specific sections.

- Class **SymbolVendorWasm** takes care of DWARF data for a ObjectFileWasm, which can be  either embedded in the modules, or stripped into a separate Wasm module which only contains DWARF sections.

- In WebAssembly, linear memory is disjointed from code space. The VM can load multiple instances of a module, which logically share the same code.

Class **DynamicLoaderWasmDYLD** manages the mapping of Wasm code address in the debuggee address space.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D71575

Files:
  lldb/include/lldb/Utility/ArchSpec.h
  lldb/source/API/SystemInitializerFull.cpp
  lldb/source/Plugins/DynamicLoader/CMakeLists.txt
  lldb/source/Plugins/DynamicLoader/WASM-DYLD/CMakeLists.txt
  lldb/source/Plugins/DynamicLoader/WASM-DYLD/DynamicLoaderWasmDYLD.cpp
  lldb/source/Plugins/DynamicLoader/WASM-DYLD/DynamicLoaderWasmDYLD.h
  lldb/source/Plugins/ObjectFile/CMakeLists.txt
  lldb/source/Plugins/ObjectFile/WASM/CMakeLists.txt
  lldb/source/Plugins/ObjectFile/WASM/ObjectFileWasm.cpp
  lldb/source/Plugins/ObjectFile/WASM/ObjectFileWasm.h
  lldb/source/Plugins/SymbolVendor/CMakeLists.txt
  lldb/source/Plugins/SymbolVendor/WASM/CMakeLists.txt
  lldb/source/Plugins/SymbolVendor/WASM/SymbolVendorWasm.cpp
  lldb/source/Plugins/SymbolVendor/WASM/SymbolVendorWasm.h
  lldb/source/Utility/ArchSpec.cpp
  lldb/unittests/ObjectFile/CMakeLists.txt
  lldb/unittests/ObjectFile/WASM/CMakeLists.txt
  lldb/unittests/ObjectFile/WASM/TestObjectFileWasm.cpp
  llvm/include/llvm/BinaryFormat/ELF.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D71575.234168.patch
Type: text/x-patch
Size: 59691 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20191216/a7224436/attachment-0001.bin>