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

[Paolo Severini via Phabricator via lldb-commits]

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