LLDB don't show frame variables while debugging
Closed this issue · 15 comments
Compile the following code with crystal build -d a.cr:
a = 0
b = 1
b = aUsing GDB:
$ gdb -q a
Reading symbols from a...done.
(gdb) b a.cr:1
Breakpoint 1 at 0x432ec9: file /home/main/Projects/Experiments/a.cr, line 1.
(gdb) r
Starting program: /home/main/Projects/Experiments/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff68ca700 (LWP 17885)]
Thread 1 "a" hit Breakpoint 1, __crystal_main () at /home/main/Projects/Experiments/a.cr:1
1 a = 0
(gdb) n
2 b = 1
(gdb) n
3 b = a
(gdb) info locals
a = 0
b = 1
(gdb) c
Continuing.
(gdb) [Thread 0x7ffff68ca700 (LWP 17885) exited]
[Inferior 1 (process 17881) exited normally]Using LLDB:
$ lldb a
(lldb) target create "a"
Current executable set to 'a' (x86_64).
(lldb) b /home/main/Projects/Experiments/a.cr:1
Breakpoint 1: where = a`__crystal_main + 1529, address = 0x0000000000432ec9
(lldb) r
Process 17664 launched: '/home/main/Projects/Experiments/a' (x86_64)
Process 17664 stopped
* thread #1, name = 'a', stop reason = breakpoint 1.1
frame #0: a`__crystal_main at a.cr:1
-> 1 a = 0
2 b = 1
3 b = a
(lldb) s
Process 17664 stopped
* thread #1, name = 'a', stop reason = step in
frame #0: a`__crystal_main at a.cr:2
1 a = 0
-> 2 b = 1
3 b = a
(lldb) fr v
(lldb) frame variable
(lldb) fr v
(lldb) c
Process 17664 resuming
Process 17664 exited with status = 0 (0x00000000)Testing a C file gcc -ggdb a.c:
int main() {
int a = 0;
int b = 1;
b = a;
return 0;
}$ lldb a.out
(lldb) target create "a.out"
Current executable set to 'a.out' (x86_64).
(lldb) b /home/main/Projects/Experiments/a.c:2
Breakpoint 1: where = a.out`main + 4 at a.c:2, address = 0x00000000004004aa
(lldb) r
Process 18050 launched: '/home/main/Projects/Experiments/a.out' (x86_64)
Process 18050 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: a.out`main at a.c:2
1 int main() {
-> 2 int a = 0;
3 int b = 1;
4 b = a;
5 return 0;
6 }
(lldb) n
Process 18050 stopped
* thread #1, name = 'a.out', stop reason = step over
frame #0: a.out`main at a.c:3
1 int main() {
2 int a = 0;
-> 3 int b = 1;
4 b = a;
5 return 0;
6 }
(lldb) n
Process 18050 stopped
* thread #1, name = 'a.out', stop reason = step over
frame #0: a.out`main at a.c:4
1 int main() {
2 int a = 0;
3 int b = 1;
-> 4 b = a;
5 return 0;
6 }
(lldb) fr v
(int) a = 0
(int) b = 1
(lldb) c
Process 18050 resuming
Process 18050 exited with status = 0 (0x00000000)Can you reproduce this issue?
Versions used:
$ crystal -v
Crystal 0.22.0 (2017-04-22) LLVM 4.0.0
$ lldb --version
lldb version 4.0.0
Maybe related: rust-lang/rust#33062
I think this issue is important, because debugging like "pry" is desiring among people interested in Crystal. (me, too.)
see: https://stackoverflow.com/questions/35491883/is-it-any-crystal-debuggers-like-pry
And, I think this issue is also related to IDE support.
This sounds like an lldb issue as per rust-lang/rust#33062 (comment)
If LLDB doesn't understand the DW_AT_language, it won't default to a C-like language, and thus won't work. A solution would be to fix lldb so it supports Crystal (e.g. as an alias for C or C++), or just use gdb instead.
Oh ... Thanks, @ysbaddaden.
However, is gdb also insufficiently? For example, I got the following result. I can't print Union Types variable.
$ crystal -v
Crystal 0.22.0 [3c71228] (2017-04-20) LLVM 3.5.0
$ cat sample.cr
debugger
x = 1
y = 2
z = (y < 1) ? 1 : "a"
puts typeof(z)
puts x
$ crystal build -d sample.cr
$ gdb ./sample
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./sample...done.
(gdb) run
Starting program: /root/how_to_debug_crystal/sample
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff71d1700 (LWP 417)]
Program received signal SIGTRAP, Trace/breakpoint trap.
__crystal_main () at /root/how_to_debug_crystal/sample.cr:2
2 x = 1
(gdb) n
3 y = 2
(gdb) n
4 z = (y < 1) ? 1 : "a"
(gdb) n
6 puts typeof(z)
(gdb) n
(Int32 | String)
7 puts x
(gdb) print z
No symbol "z" in current context.
(gdb) info locals
x = 1
y = 2
(gdb)
Can not debug any more with gdb?
Debug support is minimal: file line and basic types are defined. If I recall correctly we don't detail the layout of more complex types, so gdb can't print them, because it doesn't know how to, and since we don't detail the type it's likely it doesn't know about the variable at all.
I see.
I'm interested in debugging, so I'll think about it for a while.
Thanks!
BTW, I'm using This extension to debug binaries in VSCode.
Maybe using gdb prettyprinters, it can improve something.
@crisward and @ysbaddaden Do you know how can I use pretty printers with gdb and crystal?
Something like Rust and C++: WebFreak001/code-debug#107
|
Replace own value parser with GDB's variable objects interface.
Tested with |
I just got this in crystal: 👇
I need to use some trick to see variable value:
I discovered some tricks to debug crystal using GDB, see here 👉 https://stackoverflow.com/questions/46369703/crystal-debugging-with-gdb
@ysbaddaden Does not seem like a LLDB issue as I tried compiling crystal with DW_AT_language set to C(0x02) and C(0x04)++ and neither gave any output for frame variable.
Is there any update on this issue?
I am having this problem and it is really frustrating to not have a debugger.
I'm having success seeing local variables when debugging with https://github.com/vadimcn/vscode-lldb.
Breakpoints set in the GUI seem to work, too. 🎉️
@chances and you can use the custom formatters too https://dev.to/bcardiff/debug-crystal-in-vscode-via-codelldb-3lf
This seems to be fixed already:
a = 0
b = 1
debugger
b = a
debugger(gdb) c
Continuing.
[New Thread 0x7ffff7a57640 (LWP 239037)]
[New Thread 0x7ffff7256640 (LWP 239038)]
[New Thread 0x7ffff6a55640 (LWP 239039)]
Thread 1 "test" received signal SIGTRAP, Trace/breakpoint trap.
0x000055555559bd05 in __crystal_main () at /home/quinton/crystal/crystal/test.cr:3
3 debugger
(gdb) info locals
a = 0
b = 1
(gdb) c
Continuing.
Thread 1 "test" received signal SIGTRAP, Trace/breakpoint trap.
0x000055555559bd16 in __crystal_main () at /home/quinton/crystal/crystal/test.cr:5
5 debugger
(gdb) info locals
a = 0
b = 0
(lldb) c
Process 238306 resuming
Process 238306 stopped
* thread #1, name = 'test', stop reason = signal SIGTRAP
frame #0: 0x000055555559bd05 test`__crystal_main at test.cr:3:1
1 a = 0
2 b = 1
-> 3 debugger
4 b = a
5 debugger
(lldb) fr v
(int) a = 0
(int) b = 1
(lldb) c
Process 238306 resuming
Process 238306 stopped
* thread #1, name = 'test', stop reason = signal SIGTRAP
frame #0: 0x000055555559bd16 test`__crystal_main at test.cr:5:1
2 b = 1
3 debugger
4 b = a
-> 5 debugger
(lldb) fr v
(int) a = 0
(int) b = 0