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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
