Hi all, I'm about to implement qfThreadInfo/qsThreadInfo in the lldb-gdbserver (llgs) branch<https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64>. The qsThreadInfo only gets called when the full thread list couldn't fit into the qfThreadInfo packet. That brings up a question I haven't paid too much attention to yet - maximum client packet length.
I seem to recall there being some max client-bound packet length that a stub should assume unless something else has been negotiated. The two cases I care about are (1) llgs talking to an lldb client (that presumably could arrange for a larger max packet size, and/or can use the full lldb gdb remote packet extensions), and (2) llgs talking to another client that is adhering to the gdb-remote protocol. It looks like the stub can report its max packet size (well, looks like it must) via qSupported with a PacketSize response, listing max bytes including the leading $ and checksum suffix. But what about the reverse direction (the max packet length that the client can accept?) Is there a generally accepted default? It also seems like the qSupported request to the stub can take client-side values pushed in as suffixes to the qSupported request. Is that the way to inform the stub of the client's max accepted incoming packet length? Thanks for clarifying! Sincerely, Todd Fiala
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
