Stream: wamr

Topic: WAMR source debugging : Display local and global variables


view this post on Zulip Quentin MICHAUD (Jan 19 2024 at 13:37):

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.

WAMR source debugging basic

Last updated: Oct 23 2024 at 20:03 UTC