<div dir="ltr">Hi all,<div><br></div><div>I'm about to implement qfThreadInfo/qsThreadInfo in the <a href="https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64">lldb-gdbserver (llgs) branch</a>.  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.</div>
<div><br></div><div>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</div><div><br></div><div>(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 </div>
<div><div><br></div><div>(2) llgs talking to another client that is adhering to the gdb-remote protocol.</div><div><br></div><div>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?</div>
<div><br></div><div>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?</div>
<div><br></div><div>Thanks for clarifying!</div><div><br></div><div>Sincerely,</div><div>Todd Fiala</div><div><br></div>
</div></div>