public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Ciaran Woodward <ciaran@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdb/doc: Fix incorrect information in RSP doc Date: Wed, 24 Apr 2024 15:34:03 +0000 (GMT) [thread overview] Message-ID: <20240424153403.B8F54385840D@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f908b93b48634083338eed5183ac519db8925b38 commit f908b93b48634083338eed5183ac519db8925b38 Author: Ciaran Woodward <ciaranwoodward@xmos.com> Date: Mon Apr 22 15:09:57 2024 +0000 gdb/doc: Fix incorrect information in RSP doc The 'PacketSize' attribute of the qSupported packet was documented to be the maximum size of the packet including the frame and checksum bytes, however this is not how it was treated in the code. In reality, PacketSize is the maximum size of the data in the RSP packets, not including the framing or checksum bytes. For instance, GDB's remote.c treats it as the maximum number of data bytes. See remote_read_bytes_1, where the size of the request is capped at PacketSize/2 (for hex-encoding). Also see gdbserver's server.cc, where the internal buffer is sized as PBUFSIZ and PBUFSIZ-1 is used as PacketSize. In gdbserver's case, the buffer is not used for any of the framing or checksum characters. (I am not certain where the -1 comes from. I think it comes from back when there were no binary packets, so packets were treated as strings with null terminators). It also seems like gdbservers in the wild treat it in this way: Embocosm doc: https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html#id3078000 A quick glance over openocd's gdb_server.c gdb_put_packet_inner() function shows that the internal buffer also excludes the framing and checksum. Likewise, qEmu's gdbstub.c allocates PacketSize bytes for the internal packet contents, and PacketSize+4 for the full frame. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Pedro Alves <pedro@palves.net> Diff: --- gdb/doc/gdb.texinfo | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 31a531ee992..b2e9faac82d 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -44953,7 +44953,7 @@ These are the currently defined stub features, in more detail: The remote stub can accept packets up to at least @var{bytes} in length. @value{GDBN} will send packets up to this size for bulk transfers, and will never send larger packets. This is a limit on the -data characters in the packet, including the frame and checksum. +data characters in the packet, not including the frame and checksum. There is no trailing NUL byte in a remote protocol packet; if the stub stores packets in a NUL-terminated format, it should allow an extra byte in its buffer for the NUL. If this stub feature is not supported,
reply other threads:[~2024-04-24 15:34 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240424153403.B8F54385840D@sourceware.org \ --to=ciaran@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).