<div dir="ltr">I found a bit of interesting content in the qSupported docs on the max packet length that the stub can assume of the gdb remote client end (<a href="https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qSupported">https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qSupported</a>):<div>
<br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">Any </span><small style="color:rgb(0,0,0);font-family:Times">GDB</small><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> which sends a ‘</span><samp style="color:rgb(0,0,0)">qSupported</samp><span style="color:rgb(0,0,0);font-family:Times;font-size:medium">’ packet supports receiving packets of unlimited length (earlier versions of </span><small style="color:rgb(0,0,0);font-family:Times">GDB</small><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"> may reject overly long responses).</span></div>
</blockquote><div><span style="color:rgb(0,0,0);font-family:Times;font-size:medium"><br></span></div><div>So it may be unclear to me exactly what the max length I can assume the stub can send until I get this packet, but after the stub receives that, it seems like any length goes.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 30, 2014 at 8:51 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">Hey Matthew,<div><br></div><div>Thanks for your thoughts on this. Just had a minute to dig around the code a bit. I was thinking the potential limit on the stub => client communication was more oriented towards max packet sizes expected over the (historically) not-assumed-to-be-reliable communication pipe between the gdb client and stub.</div>
<div><br></div><div>I found the code that triggered my question on this, in RNBRemote.h:</div><div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div><font face="courier new, monospace" size="1">/* Generally speaking, you can't assume gdb can receive more than 399 bytes</font></div>
<div><font face="courier new, monospace" size="1"> at a time with a random gdb. This bufsize constant is only specifying</font></div><div><font face="courier new, monospace" size="1"> how many bytes gdb can *receive* from debugserver -- it tells us nothing</font></div>
<div><font face="courier new, monospace" size="1"> about how many bytes gdb might try to send in a single packet. */</font></div><div><font face="courier new, monospace" size="1">#define DEFAULT_GDB_REMOTE_PROTOCOL_BUFSIZE 399</font></div>
</div><div><br></div></blockquote>So my question was really where did this number come from, and in which cases does it really matter, and is there some way to negotiate a much larger number or discard it entirely if - say - the communication medium is known to be reliable.</div>
</div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">On Thu, May 22, 2014 at 12:45 AM, Matthew Gardiner <span dir="ltr"><<a href="mailto:mg11@csr.com" target="_blank">mg11@csr.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Todd Fiala wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br>
</blockquote></div>
I can't see "PacketSize" listed as a gdbfeature, in the "GDB Remote Serial Protocol" appendix. (I assuming that the document lists gdbfeature and stubfeature as exclusive sets).<br>
<br>
It's possible that the client is intended to tolerate large packets, since it is envisaged to run on a machine with sufficient memory to keep reallocing it's recv buffer. However, (I'm guessing here) the stub is intended to run on a more constrained environment, and where it may not be possible to allocate as much memory, and therefore is reliant on a statically allocated fixed-size buffer. As a consequence, the designers of the protocol may have decided that there must be a way to constrain the client, but that the stub need not be similarly constrained? Well, that's my take on it.<br>
<br>
Matt<br>
<br>
<br>
<br>
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom<br>
More information can be found at <a href="http://www.csr.com" target="_blank">www.csr.com</a>. Keep up to date with CSR on our technical blog, <a href="http://www.csr.com/blog" target="_blank">www.csr.com/blog</a>, CSR people blog, <a href="http://www.csr.com/people" target="_blank">www.csr.com/people</a>, YouTube, <a href="http://www.youtube.com/user/CSRplc" target="_blank">www.youtube.com/user/CSRplc</a>, Facebook, <a href="http://www.facebook.com/pages/CSR/191038434253534" target="_blank">www.facebook.com/pages/CSR/<u></u>191038434253534</a>, or follow us on Twitter at <a href="http://www.twitter.com/CSR_plc" target="_blank">www.twitter.com/CSR_plc</a>.<br>
New for 2014, you can now access the wide range of products powered by aptX at <a href="http://www.aptx.com" target="_blank">www.aptx.com</a>.<br>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr">-Todd</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-Todd</div>
</div>