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

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

What if the wasm engine actually made some effort to present a more "conventional" view of the wasm "process"? I.e., in addition to the "implied" PC, we could have an "implied" SP (and maybe an FP too). Then it could lay out the call stack and the function arguments in "memory", and point the "SP" to it so that lldb is able to reconstruct the frames&variables using the "normal" algorithm. For the sake of exposition, lets assume the following "encoding" of the 64 bit memory space:

  unsigned:16 type; // 0x5555 = stack
  unsigned:16 tid; // are there threads in wasm?
  unsigned:16 frame; // grows down, 0x0000 = bottommost frame (main), 0x0001 = second from bottom, etc.
  unsigned:16 address;

Then the engine could say that the "SP" of thread 0x1234 is `0x5555123400050000`, "FP" is `0x5555123400048010 and the have the memory contents be

  0x5555123400048020: // third "local" (of frame 4)
  0x5555123400048018: // second "local" (of frame 4)
  0x5555123400048010: // first "local" (of frame 4)
  0x5555123400048008: 0x5555123400038010 // previous FP (frame 3)
  0x5555123400048000: ???? // previous PC (frame 3)
  0x5555123400040010: // third "argument" (of frame 4)
  0x5555123400040008: // second "argument" (of frame 4)
  0x5555123400040000: // first "argument" (of frame 4)
  0x5555123400038020: // third "local" (of frame 3)
  0x5555123400038018: // second "local" (of frame 3)
  0x5555123400038010: // first "local" (of frame 3)
  0x5555123400038008: 0x5555123400028010 // previous FP (frame 2)
  0x5555123400038000: ???? // previous PC (frame 2)
  etc.

Then all it would be needed is to translate `DW_OP_WASM_location` into an appropriate `FP+offset` combo. Somehow...

I realize that this is basically throwing the problem "over the fence", and asking the other side to deal with things, but I am starting to get sceptical that we will be able to come up with a satisfactory solution within lldb.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78801