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 <[email protected]> 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
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
