<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:12.727272033691406px">It looks like the stub can report its max packet size (well, looks like it must) </span><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">Ignore the "must" part.  I think I was misreading the table that described it.  I think the required part was that the size must be specified if the PacketSize argument is included.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.727272033691406px">The rest of the question still stands.</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 21, 2014 at 9:27 AM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-Todd</div>
</div>