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

[Todd Fiala]

Hey Matthew,

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.

I found the code that triggered my question on this, in RNBRemote.h:

/* Generally speaking, you can't assume gdb can receive more than 399 bytes
   at a time with a random gdb.  This bufsize constant is only specifying
   how many bytes gdb can *receive* from debugserver -- it tells us nothing
   about how many bytes gdb might try to send in a single packet.  */
#define DEFAULT_GDB_REMOTE_PROTOCOL_BUFSIZE 399

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.


On Thu, May 22, 2014 at 12:45 AM, Matthew Gardiner <mg11 at csr.com> wrote:

> Todd Fiala wrote:
>
>>
>> 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?
>>
> 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).
>
> 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.
>
> Matt
>
>
>
> 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
> More information can be found at www.csr.com. Keep up to date with CSR on
> our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
> YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> www.twitter.com/CSR_plc.
> New for 2014, you can now access the wide range of products powered by
> aptX at www.aptx.com.
>



-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140530/9a4f4f6a/attachment.html>