New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Two way socket communication with lldb #53
Comments
Sure, I'd be glad to see this implemented. Would it work for stack frame navigation (up, down) too? These also require jumps in the source code window without actually changing the debugger state. |
I'm going to implement a way to execute commands via the side channel (see |
@lanza, could you please check this out? |
So this is a good implementation and idea, but it's not the same as I was talking about in this issue. The patch you just landed adds the ability to call So from here on out you should be able to map, for example, This issue was about a different topic, though. A clear example of this API usage is at https://reviews.llvm.org/source/lldb/browse/lldb/trunk/examples/python/performance.py. You can walk through this script in PDB to observe what it does. I also just pushed a WIP commit (more of a demo of the idea) to lanza@c22f74f. |
Right, I ignored the first part intentionally. Currently, the debugger state is (tried to be) recognized by parsing the interpreter output. That's a little bit unreliable, but it works quite well for both GDB and PDB. I'd like to keep the implementation unified. But probably, I should agree with you that since LLDB offers a good API, we could harness it through Python without even parsing the output. |
lldb has listeners and event emitters that will let you know when the state changes and events in the debugger. e.g. you can register to listen for
StateChanged
and check ifStateStopped
andStopReasonBreakpoint
. This will fix thebt
bug where nvim-gdb switches files 14 times for all 14 stack frames due to lldb printing out 14 frames and nvim-gdb parsing 14 different cues to switch files.And obviously this opens up the possibilities for many other improvements once you get that going. (e.g. querying
frame var
after every stop and updating a side panel with the variable info, thread lists, frame lists, memory views, etc etc etc)Here's a little example script that demonstrates the APIs:
https://github.com/apple/swift-lldb/blob/stable/examples/python/performance.py
Any interest on this idea?
The text was updated successfully, but these errors were encountered: