[Lldb-commits] [PATCH] D72751: [LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debugging
Paolo Severini via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Wed Jan 22 23:54:27 PST 2020
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:
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()`.
- `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:
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?
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 20000 bytes
Desc: not available
More information about the lldb-commits