wasmtime / Issue #1613 Debugging C/C++ WASM code doesn't ... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / Issue #1613 Debugging C/C++ WASM code doesn't ...

Wasmtime GitHub notifications bot (Apr 28 2020 at 02:21):

TerryGuo opened Issue #1613:

Hi there,
I built a wasm toolchain from the recent LLVM10 release and compile my C code to wasm with command :

clang --target=wasm32 fib.c -nostdlib -Wl,-entry=fib -g -O0 -o fib.wasm

Then debug it with the wasmtime built from the lastest master branch:

lldb -- ./wasmtime/target/release/wasmtime run fib.wasm --invoke fib 40

The breakpoint to function fib works well, but the local variables in my C code can't be viewed. Maybe I am not doing things in the right way. Could some one please help me? Thanks in advance.

Current executable set to './wasmtime/target/release/wasmtime' (x86_64). [0/1836]
(lldb) settings set -- target.run-args "-g" "fib.wasm" "--invoke" "fib" "40"
(lldb) b fib
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 26871 launched: '/data/home/terry/projects/wasmtime/wasmtime/target/release/wasmtime' (x86_64)
1 location added to breakpoint 1
warning: using --invoke with a function that takes arguments is experimental and may break in the future
Process 26871 stopped * thread #1, name = 'wasmtime', stop reason = breakpoint 1.1
frame #0: 0x00007ffff6209026 JIT(0x555555dccfb0)fib(n=<unavailable>) at fib.c:2:13 1 int fib(int n) { -> 2 int i, t, a = 0, b = 1; 3 for (i = 0; i < n; i++) { 4 t = a; 5 a = b; 6 b += t; 7 } (lldb) n Process 26871 stopped * thread #1, name = 'wasmtime', stop reason = step over frame #0: 0x00007ffff6209030 JIT(0x555555dccfb0)fib(n=<unavailable>) at fib.c:3:10
1 int fib(int n) {
2 int i, t, a = 0, b = 1;
-> 3 for (i = 0; i < n; i++) {
4 t = a;
5 a = b;
6 b += t;
7 }
(lldb) p t
error: Couldn't materialize: couldn't get the value of variable t: Expression stack needs at least 1 item for DW_OP_plus_uconst.
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
(lldb)

And my fib C code is as below:
int fib(int n) {
  int i, t, a = 0, b = 1;
  for (i = 0; i < n; i++) {
    t = a;
    a = b;
    b += t;
  }
  return b;
}

Wasmtime GitHub notifications bot (Apr 28 2020 at 08:15):

tschneidereit commented on Issue #1613:

CC @yurydelendik

Wasmtime GitHub notifications bot (Apr 28 2020 at 08:19):

bjorn3 commented on Issue #1613:

You also need to pass -g to `wasmtime. Otherwise it won't generate debuginfo for the jitted code.

Wasmtime GitHub notifications bot (Apr 28 2020 at 08:21):

tschneidereit commented on Issue #1613:

Oh, of course. I wonder if we could warn about this somehow. @yurydelendik could we do something like detect that a debugger is attached and warn if we don't have debug info for the JITted code?

Wasmtime GitHub notifications bot (Apr 28 2020 at 11:27):

TerryGuo commented on Issue #1613:

@bjorn3 Sorry that I pasted wrong command line. The -g option doesn't help.

terry@wasm-test01:~/projects/wasmtime$ lldb -- ./wasmtime/target/release/wasmtime -g fib.wasm --invoke fib 40
(lldb) target create "./wasmtime/target/release/wasmtime"
Current executable set to './wasmtime/target/release/wasmtime' (x86_64).
(lldb) settings set -- target.run-args "-g" "fib.wasm" "--invoke" "fib" "40"
(lldb) b fib
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 5489 launched: '/data/home/terry/projects/wasmtime/wasmtime/target/release/wasmtime' (x86_64)
1 location added to breakpoint 1
warning: using --invoke with a function that takes arguments is experimental and may break in the future
Process 5489 stopped * thread #1, name = 'wasmtime', stop reason = breakpoint 1.1
frame #0: 0x00007ffff7fba026 JIT(0x555555dc5310)fib(n=<unavailable>) at fib.c:2:13 1 int fib(int n) { -> 2 int i, t, a = 0, b = 1; 3 for (i = 0; i < n; i++) { 4 t = a; 5 a = b; 6 b += t; 7 } (lldb) n Process 5489 stopped * thread #1, name = 'wasmtime', stop reason = step over frame #0: 0x00007ffff7fba030 JIT(0x555555dc5310)fib(n=<unavailable>) at fib.c:3:10
1 int fib(int n) {
2 int i, t, a = 0, b = 1;
-> 3 for (i = 0; i < n; i++) {
4 t = a;
5 a = b;
6 b += t;
7 }
(lldb) p t
error: Couldn't materialize: couldn't get the value of variable t: Expression stack needs at least 1 item for DW_OP_plus_uconst.
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
(lldb)

Wasmtime GitHub notifications bot (Apr 28 2020 at 13:51):

yurydelendik commented on Issue #1613:

2 things might be happening here:

DW_AT_frame_base patch for LLVM came late for v10 release so it might not be included (I'm building fib-wasm.wasm file with clang-11)

There is big refactoring and bug fix at https://github.com/bytecodealliance/wasmtime/pull/1572 -- it might be related here

Wasmtime GitHub notifications bot (Apr 28 2020 at 18:17):

ggreif commented on Issue #1613:

I _think_ I found something fishy. These lines in expression.rs:
                let wasm_start = local_range.start;
                let wasm_end = local_range.end;
(around line 490) seem bogus. local_range is a Cranelift type ValueLocRange, which most probably don't contain Wasm bytecode offsets, but function-relative machine-code offsets. Then doing translate_ranges with those won't make sense. Instead the machine offset ranges must be iterated in the FuncTransform based on their gen_start and gen_end.

@yurydelendik can you confirm (some of) this?

I keep working on this.

Wasmtime GitHub notifications bot (Apr 28 2020 at 18:19):

ggreif edited a comment on Issue #1613:

I _think_ I found something fishy. These lines in expression.rs:
                let wasm_start = local_range.start;
                let wasm_end = local_range.end;
(around line 474) seem bogus. local_range is a Cranelift type ValueLocRange, which most probably don't contain Wasm bytecode offsets, but function-relative machine-code offsets. Then doing translate_ranges with those won't make sense. Instead the machine offset ranges must be iterated in the FuncTransform based on their gen_start and gen_end.

@yurydelendik can you confirm (some of) this?

I keep working on this.

Wasmtime GitHub notifications bot (Apr 28 2020 at 18:21):

ggreif edited a comment on Issue #1613:

I _think_ I found something fishy. These lines in expression.rs:
                let wasm_start = local_range.start;
                let wasm_end = local_range.end;
(around line 474) seem bogus. local_range has a Cranelift type ValueLocRange, which most probably don't contain Wasm bytecode offsets, but function-relative machine-code offsets. Then doing translate_ranges with those won't make sense. Instead the machine offset ranges must be iterated in the FuncTransform based on their gen_start and gen_end.

@yurydelendik can you confirm (some of) this?

I keep working on this.

Wasmtime GitHub notifications bot (Apr 28 2020 at 18:25):

ggreif edited a comment on Issue #1613:

I _think_ I found something fishy. These lines in expression.rs:
                let wasm_start = local_range.start;
                let wasm_end = local_range.end;
(around line 474) seem bogus. local_range has a Cranelift type ValueLocRange, which most probably don't contain Wasm bytecode offsets (WasmAddress?), but function-relative machine-code offsets (GeneratedAddress?). Then doing translate_ranges with those won't make sense. Instead the machine offset ranges must be iterated in the FuncTransform based on their gen_start and gen_end.

@yurydelendik can you confirm (some of) this?

I keep working on this.

Wasmtime GitHub notifications bot (Apr 28 2020 at 18:28):

ggreif edited a comment on Issue #1613:

Alert: below comment probably off-topic for this issue. I'll start a new one as soon as I have something more than a hunch. Sorry for spamming!

I _think_ I found something fishy. These lines in expression.rs:
                let wasm_start = local_range.start;
                let wasm_end = local_range.end;
(around line 474) seem bogus. local_range has a Cranelift type ValueLocRange, which most probably don't contain Wasm bytecode offsets (WasmAddress?), but function-relative machine-code offsets (GeneratedAddress?). Then doing translate_ranges with those won't make sense. Instead the machine offset ranges must be iterated in the FuncTransform based on their gen_start and gen_end.

@yurydelendik can you confirm (some of) this?

I keep working on this.

Wasmtime GitHub notifications bot (Apr 28 2020 at 18:39):

ggreif edited a comment on Issue #1613:

Alert: below comment probably off-topic for this issue. I'll start a new one as soon as I have something more than a hunch. Sorry for spamming!

I _think_ I found something fishy. These lines in expression.rs:
                let wasm_start = local_range.start;
                let wasm_end = local_range.end;
(around line 474) seem bogus. local_range has a Cranelift type ValueLocRange, which most probably doesn't contain Wasm bytecode offsets (WasmAddress?), but function-relative machine-code offsets (GeneratedAddress?). Then doing translate_ranges with those won't make sense. Instead the machine offset ranges must be iterated in the FuncTransform based on their gen_start and gen_end.

@yurydelendik can you confirm (some of) this?

I keep working on this.

Wasmtime GitHub notifications bot (Apr 28 2020 at 19:04):

yurydelendik commented on Issue #1613:

I _think_ I found something fishy. These lines in expression.rs:

let wasm_start = local_range.start; let wasm_end = local_range.end;

@yurydelendik can you confirm (some of) this?

@ggreif Yes, it is fixed in #1572. Can you review entire PR? ;)

Wasmtime GitHub notifications bot (Apr 30 2020 at 03:24):

TerryGuo commented on Issue #1613:

@yurydelendik @ggreif Thanks for your work. I can confirm that the variables in C code can be viewed with the latest llvm trunk and the fix in #1572.

Wasmtime GitHub notifications bot (Apr 30 2020 at 11:19):

ggreif commented on Issue #1613:

Fixed by #1572.

Wasmtime GitHub notifications bot (Apr 30 2020 at 13:08):

yurydelendik closed Issue #1613:

Hi there,
I built a wasm toolchain from the recent LLVM10 release and compile my C code to wasm with command :

clang --target=wasm32 fib.c -nostdlib -Wl,-entry=fib -g -O0 -o fib.wasm

Then debug it with the wasmtime built from the lastest master branch:

lldb -- ./wasmtime/target/release/wasmtime run fib.wasm --invoke fib 40

The breakpoint to function fib works well, but the local variables in my C code can't be viewed. Maybe I am not doing things in the right way. Could some one please help me? Thanks in advance.

Current executable set to './wasmtime/target/release/wasmtime' (x86_64). [0/1836]
(lldb) settings set -- target.run-args "-g" "fib.wasm" "--invoke" "fib" "40"
(lldb) b fib
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 26871 launched: '/data/home/terry/projects/wasmtime/wasmtime/target/release/wasmtime' (x86_64)
1 location added to breakpoint 1
warning: using --invoke with a function that takes arguments is experimental and may break in the future
Process 26871 stopped * thread #1, name = 'wasmtime', stop reason = breakpoint 1.1
frame #0: 0x00007ffff6209026 JIT(0x555555dccfb0)fib(n=<unavailable>) at fib.c:2:13 1 int fib(int n) { -> 2 int i, t, a = 0, b = 1; 3 for (i = 0; i < n; i++) { 4 t = a; 5 a = b; 6 b += t; 7 } (lldb) n Process 26871 stopped * thread #1, name = 'wasmtime', stop reason = step over frame #0: 0x00007ffff6209030 JIT(0x555555dccfb0)fib(n=<unavailable>) at fib.c:3:10
1 int fib(int n) {
2 int i, t, a = 0, b = 1;
-> 3 for (i = 0; i < n; i++) {
4 t = a;
5 a = b;
6 b += t;
7 }
(lldb) p t
error: Couldn't materialize: couldn't get the value of variable t: Expression stack needs at least 1 item for DW_OP_plus_uconst.
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
(lldb)

And my fib C code is as below:
int fib(int n) {
  int i, t, a = 0, b = 1;
  for (i = 0; i < n; i++) {
    t = a;
    a = b;
    b += t;
  }
  return b;
}

Wasmtime GitHub notifications bot (Dec 06 2020 at 17:49):

abbec commented on Issue #1613:

Quick question @yurydelendik, do you have a link to the DW_AT_frame_base patch so I can confirm I have It because I see the same problem.

Wasmtime GitHub notifications bot (Dec 06 2020 at 19:27):

yurydelendik commented on Issue #1613:

do you have a link to the DW_AT_frame_base patch so I can confirm I have It because I see the same problem.

AFAIK DW_AT_frame_base related patch, not my though, landed in LLVM (since version 10?)

Wasmtime GitHub notifications bot (Dec 06 2020 at 22:50):

abbec commented on Issue #1613:

Might very well be the case :) I just could Not find any info searching for that.

Last updated: Dec 23 2024 at 12:05 UTC