Two way socket communication with lldb

[sakhnik]

Two way socket communication with lldb

[sakhnik]

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.

[sakhnik]

I'm going to implement a way to execute commands via the side channel (see gdb.customCommand in the branch eval).
User autocommands can be used to notify about the debugger backend state.

[sakhnik]

@lanza, could you please check this out?

I think the idea can be taken even further. The plugin could provide a function to open a window that would "watch" an expression.

[lanza]

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 HandleCommand over a socket interface. So it lets you hide NvimGDB's HandleCommand usage. HandleCommand is the exact same function that is called when you submit something on lldb's command line interface.

So from here on out you should be able to map, for example, GdbBreakpointToggle to lua gdb.customCommand('rb file:line') instead of simply sending it to the terminal buffer in neovim. This could let you hide nvim-gdb's implementation from the user.

This issue was about a different topic, though. lldb_commands.py currently listens to the lua client for requests info-breakpoints and handle-command with the server function. But you can also setup another thread to listen to events from lldb itself and then forward that information to the lua client. This way nvim-gdb can be told when lldb stops at a breakpoint instead of scraping the stdout of the terminal buffer for the frame info.

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.

[sakhnik]

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.