[Lldb-commits] [PATCH] D78801: [LLDB] Add class WasmProcess for WebAssembly debugging

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

I forgot I wanted to respond to this part.

In D78801#2014515 <https://reviews.llvm.org/D78801#2014515>, @paolosev wrote:

> The fact that the code address space is separated from the memory address space is really what makes things complicated. However, we know for sure that every time that all memory reads made while evaluating DWARF expressions or variables always target the module memory space, never the code space.
>
> I must confess that had not really tested `target variable` so far; I did it today and I found that it already //almost// works. What happens is that the location of the global variable is calculated with DWARFExpression::Evaluate (in my tests I only see `DW_OP_addr`, but maybe there could be other ways?) and there it calls Value::ConvertToLoadAddress() passing the correct module, and this produces an address in the form `module_id|offset`, which is then used in Value::GetValueAsData(), which currently sends qWasmMem requests.


Ok, I can see how that would sort of work. But what about dereferencing global variables (`target variable *global_ptr`)? I have a feeling that will be trickier because that address doesn't go through file->load address conversion, as it's expected to already be a load address. I don't think that we will automatically infer the right "module" for it, and I'm not sure how to make lldb infer the right module/address space there without teaching it a lot more about non-flat address spaces.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78801