[Lldb-commits] [PATCH] D72751: [LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debugging

[Paolo Severini via Phabricator via lldb-commits]

paolosev updated this revision to Diff 239784.
paolosev added a comment.

I have verified the logic of the dynamic loader quite carefully, but there are a couple of things to clarify.

A Wasm module is loaded at a 64 bit address, where the upper 32 bits are used as module identifier. Let’s say that we have a module with Id==4, so it will be loaded at address 0x00000004`00000000.  Each section is loaded at its relative file offset. Therefore if the code section starts at file offset 0x4d in the Wasm module, we call:
Target::SetSectionLoadAddress(section_sp, 0x40000004d).

The module can also contain embedded DWARF sections, which will also be loaded at their relative file offset in the same way. And since there cannot be duplicated sections in a module, there is no overlapping, we can always convert a load address back into a section.

However, there are two complications.

The first is that we need to call `Target::SetSectionLoadAddress()` twice, from two different places. First we need to call `Target::SetSectionLoadAddress()` in `ObjectFileWasm::SetLoadAddress()`, and then again in `DynamicLoaderWasmDYLD::DidAttach()`. The reason for this seems to originate in the sequence of function calls:

In `DynamicLoaderWasmDYLD::DidAttach()` we call `ProcessGDBRemote::LoadModules()` to get list of loaded modules from the remote (Wasm engine).
`ProcessGDBRemote::LoadModules()` calls, first:

- `DynamicLoaderWasmDYLD::LoadModuleAtAddress()` and from there:
  1. `DynamicLoader::UpdateLoadedSections() -> ObjectFileWasm::SetLoadAddress()`
  2. `Target::GetImages()::AppendIfNeeded(module) -> ProcessGDBRemote::ModulesDidLoad() -> JITLoaderList::ModulesDidLoad() -> Module::GetSymbolFile() -> SymbolFileDWARF::CalculateAbilities()`. Here we initialize the symbols for the module, and set `m_did_load_symfile`, but for this to work we need to have already set the load address for each section, in the previous `ObjectFileWasm::SetLoadAddress()`.

then:

- `Target::SetExecutableModule() -> Target::ClearModules() -> SectionLoadList::Clear()`

So, at the end of `LoadModules()` in `DynamicLoaderWasmDYLD::DidAttach()` the SectionLoadList is empty, and we need to set it again by calling `Target::.SetSectionLoadAddress()` again. 
This works but the duplication is ugly; is there a way to improve this?
_

The second problem is that the Code Section needs to be initialized (in `ObjectFileWasm::CreateSections()`) with `m_file_addr = m_file_offset = 0`, and not with the actual file offset of the Code section in the Wasm file. If we set `Section::m_file_addr` and `Section::m_file_offset` to the actual code offset, the DWARF info does not work correctly.

I have some doubts regarding the DWARF data generated by Clang for a Wasm target. Looking at an example, for a Wasm module that has the Code section at offset 0x57, I see this DWARF data:

  0x0000000b: DW_TAG_compile_unit
                […]
                DW_AT_low_pc (0x0000000000000000)
                DW_AT_ranges (0x00000000
                   [0x00000002, 0x0000000e)
                   [0x0000000f, 0x0000001a)
                   [0x0000001b, 0x00000099)
                   [0x0000009b, 0x0000011c))

The documentation <https://yurydelendik.github.io/webassembly-dwarf/#pc> says that //“Wherever a code address is used in DWARF for WebAssembly, it must be the offset of an instruction relative within the Code section of the WebAssembly file.”// 
But is this correct? Shouldn't maybe code addresses be offset-ed by the file address of the Code section?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72751/new/

https://reviews.llvm.org/D72751

Files:
  lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestWasm.py
  lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/test_wasm.yaml
  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/wasm/ObjectFileWasm.cpp
  lldb/source/Plugins/ObjectFile/wasm/ObjectFileWasm.h
  lldb/tools/lldb-test/SystemInitializerTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D72751.239784.patch
Type: text/x-patch
Size: 20000 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20200123/13980586/attachment-0001.bin>