paolosev added a comment.
In D78801#2009128 <https://reviews.llvm.org/D78801#2009128>, @clayborg wrote:
> Could we just always use memory reading and have the address contain more
> info? Right now you have the top 32 bits for the module ID. Could it be
> something like:
>
> struct WasmAddress {
> uint64_t module_id:16;
> uint64_t space:4; // 0 == code, 1 == data, 2 == global, 3==local, 4 ==
> stack
> uint64_t frame_id:??;
> uint64_t addr: ??;
> }
>
>
> This would be a bitfield that would all fit into a 64 bit value and could
> then be easily sent to the GDB server with the standard m and M packets.
This is interesting. We could certainly use a few bits to specify the space `0
== code, 1 == data, 2 == global, 3==local, 4 == stack` and then have either the
module_id or the frame_index, according to the space, and just send "m" packets.
struct WasmAddress {
uint64_t scope:3;
uint64_t module_id_or_frame_index:29;
uint64_t address: 32;
}
But then these "m" packets would have to be interpreted according to these
rules by a Wasm-aware GDB-remote stub, so I am not sure we would gain much
besides avoiding the introduction of four new custom query commands.
In a function like `Value::GetValueAsData` we would still have to have
Wasm-specific code to generate the memory address in this format, and actually
there it is easier to pass the current frame_index, which is readily available,
rather than calculating the corresponding module_index.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D78801/new/
https://reviews.llvm.org/D78801
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
