<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"><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 class="">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>-- <br><div dir="ltr">-Todd</div>
</div>