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.
On 29/03/2016 10:57, Ravitheja Addepally via lldb-dev wrote:
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 ?
---Ravi
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
