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