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

[Todd Fiala]

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 (
https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qSupported
):

Any GDB which sends a ‘qSupported’ packet supports receiving packets of
unlimited length (earlier versions of GDB may reject overly long responses).


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.



On Fri, May 30, 2014 at 8:51 AM, Todd Fiala <todd.fiala at gmail.com> wrote:

> 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
>



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