[Question] GDB tracking for rustpython #4880
Replies: 2 comments 2 replies
|
How about lldb? I didn't try gdb. When trying lldb, I could do stepping sometimes well and sometimes awfully. I depends on breakpoints a lot. |
|
I will give this a shot and see if it works for me |
|
it is pretty tricky sometimes due to it stepping into some calls that are, as you say, in the rust standard library. I don't know of any way to maybe ignore these but wouldn't be surprised if some path-based filtering existed. After a while it should get better due to realizing which calls will most likely take you on random trips. I'll be moving this into discussions since it'll have more visibility |
Thanks for moving this here, this is better place for such questions.
Glad that I am not only one, guess it is probably be an issue on gdb side. I will check other tools so they work. |
Uh oh!
There was an error while loading. Please reload this page.
This not be RustPython issue per se, but I am having trouble in getting through control flow of rustpython via gdb.
In cpython (or millions other c program), I can attach debugger and flow through lexer and then to interpreter (and then finally c functions).
For example, adding breaking point to /Include/cpython/methodobject.h:46 and stepping into
func->m_selfI can go into corresponding c functions.In rustpython, stepping into jumps to rustlibs back and forth and somehow execution completes without me going to actual functions.
Note that if I attach break point to some function in *.rs, it reaches there without any issue, but this is when I know where to reach. This doesn't help if I want to find out flow and where control is going and to which function in *.rs.
Any ideas on this will be apprecitated.
Note: I also tried using rust-gdb ( gdb_load_rust_pretty_printers.py didn't really help much with prettiness, for some reason) but to no avail.
All reactions