[lldb-dev] qfThreadInfo/qsThreadInfo stub impl and max packet size

[Todd Fiala]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140521/f24d2ce7/attachment.html>