labath added a reviewer: jingham. labath added a comment. In D78801#2050449 <https://reviews.llvm.org/D78801#2050449>, @paolosev wrote:
> Hello @clayborg , @labath, > Any thoughts on this latest patch? :-) Sorry about the delay. I think that in terms of the design we've come as far as we can without making substantial changes to a lot of lldb interfaces. The question on my mind is.. is that enough? Here, I am mainly thinking about the introduction of the ExecutionContext argument to `ReadMemory`. In a universe with static flat address spaces, the argument looks flat out wrong. If one thinks of "memory" as something more dynamic, it does not seem to be that bad, as it can be viewed as the context in which to interpret the memory addresses. However, I am having trouble assigning a semantic to it besides saying "it does what webassembly needs". Maybe it's just because I live in a flat universe and lack address space intuition... Anyway, I think it would be good to get more people's opinions on this. For start, I nominate Jim. :) The problem with "looking forward to implementing more cleanly in the future with AddressSpecifiers" is that _everyone_ is looking forward to having address spaces, but noone is actually working on implementing them. And I want to be careful about accumulating technical debt like this upstream, because it's the technical debt which makes future implementations hard. In D78801#2026636 <https://reviews.llvm.org/D78801#2026636>, @paolosev wrote: > Note that WasmDWARFEvaluator::Evaluate() not only needs to handle > Wasm-specific opcodes like DW_OP_WASM_location, but might also handle in a > Wasm-specific way some "standard" opcodes. For example, static variables are > generally encoded with `DW_OP_addr`, but for WebAssembly the corresponding > offset is the offset in the module Data section, which is mapped into an area > of the Memory section when the module is loaded. So, memory reads related to > DW_OP_addr refer to a different space and should be dealt differently by the > runtime. > This makes `target variable *global_ptr` work when we have multiple > modules., because we can retrieve the module_id from the Module associated to > the DWARFExpression. I am confused by this line of reasoning. For a global variable, the DW_OP_addr describes the location of the variable itself (the value of `&global_ptr`). That is what makes it possible to display the value of the pointer (`global_ptr`). Displaying the value of the pointed-to object (`*global_ptr`) is a different thing, and AFAIK it completely bypasses any dwarf expressions. Are you saying that the value of the pointer somehow inherits the "address space" of the memory where the pointer itself is located? 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
