Hello,
I wanted to know if the remote protocol of LLDB is state less or not ? When i say state I am referring to if LLDB remembers the current process or thread being debugged (which would mean we dont need to specify that in the client to server packets ) . I was looking at the GDBRemoteCommunicationServerLLGS and found that most of the packets did not have the pid or thread id being passed to the server , so is it safe to assume that the protocol is statefull ? is this assumption also valid for all OS’s ?
The GDB RSP, which LLDB RSP is derived from is certainly state-full and maintains an notion of the current thread for queries (reading registers, etc…) and for execution commands (stepping), see the ‘H’ packet.
The RSP has evolved quite a bit however and extended packets were introduced that do take TID’s as a parameter (vcont for instance).
Hopefully someone can chip in who is more familiar with lldb-server however.
As for your other question, the RSP should however be relatively platform independent as far as state-fullness goes, I don’t think and of the upstream lldb platforms keep an kind of special state.
Disclaimer… Its been a little while since I have had to really dig into RSP so its all liable to have changed.
Hello,
I wanted to know if the remote protocol of LLDB is state less or not ? When i say state I am referring to if LLDB remembers the current process or thread being debugged (which would mean we dont need to specify that in the client to server packets ) . I was looking at the GDBRemoteCommunicationServerLLGS and found that most of the packets did not have the pid or thread id being passed to the server , so is it safe to assume that the protocol is statefull ?
Yes. There is the notion that you have one process that may or may not be there when you connect. When and if a process does exist, it assumes it won't change. Threads can be selected and many packets operate of the current thread. We have also added new packets to allow us to append a thread ID suffix to existing packets, like reading and writing registers. This allows us to save a packet round trip so we don't always have to say "set thread to thread 123" and then "read register 12".