I'm using WAMR with a custom lldb as detailed in this blog post (written by @Jun Xu if I'm not mistaken). I'm able to do what is shown in the blog post, along with displaying the Wasm bytecode using x/20i
-like instructions. An example :
(lldb) process connect -p wasm connect://127.0.0.1:1234
Process 1 stopped
* thread #1, name = 'nobody', stop reason = trace
frame #0: 0x40000000000001d4 canary
-> 0x40000000000001d4: block
0x40000000000001d6: i32.const 0
0x40000000000001d8: i32.load 3808
0x40000000000001df: br_if 0 ; 0: down to label0
(lldb) x/10i 0x40000000000001d4
-> 0x40000000000001d4: 02 40 block
0x40000000000001d6: 41 00 i32.const 0
0x40000000000001d8: 28 02 e0 9d 80 80 00 i32.load 3808
0x40000000000001df: 0d 00 br_if 0 ; 0: down to label0
0x40000000000001e1: 41 00 i32.const 0
0x40000000000001e3: 41 01 i32.const 1
0x40000000000001e5: 36 02 e0 9d 80 80 00 i32.store 3808
0x40000000000001ec: 10 87 80 80 80 00 call 7
0x40000000000001f2: 10 8a 80 80 80 00 call 10
0x40000000000001f8: 21 00 local.set 0
(lldb)
Basically, using x/i
on addresses indicated by the frame allows to see the related bytecode. It seems that it was implemented so the 32-bit Wasm code memory was mapped in 64-bit address space to 0x40000000XXXXXXXX
(from what I understood of the debugging behavior and lldb Wasm patches).
My question is, can we also dump other memory regions (local and global variables are the most interesting to me, but we can also consider function tables and every other Wasm memory type) ? I tried doing it using this 32 -> 64 bit memory mapping but was unable to find how to do it if it's effectively the way to do.
Last updated: Nov 22 2024 at 16:03 UTC