Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@linaro.org>
To: gdb-patches@sourceware.org, Alan.Hayward@arm.com
Cc: omair.javaid@linaro.org, catalin.marinas@arm.com,
	david.spickett@linaro.org, jose.marchesi@oracle.com
Subject: [PATCH 07/23] Documentation for memory tagging remote packets
Date: Wed, 15 Jul 2020 16:44:57 -0300	[thread overview]
Message-ID: <20200715194513.16641-8-luis.machado@linaro.org> (raw)
In-Reply-To: <20200715194513.16641-1-luis.machado@linaro.org>

Document the remote packet changes to support memory tagging.

gdb/doc/ChangeLog:

YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>

	* gdb.texinfo (General Query Packets): Document qMemTags and
	QMemTags.
	Document the "memory-tagging" feature.
---
 gdb/doc/gdb.texinfo | 84 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 84 insertions(+)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index a002084d5b..bc610e44cd 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -40654,6 +40654,77 @@ is a sequence of thread IDs, @var{threadid} (eight hex
 digits), from the target.  See @code{remote.c:parse_threadlist_response()}.
 @end table
 
+@item qMemTags:@var{start address}:@var{length}
+@cindex fetch memory tags
+@cindex @samp{qMemTags} packet
+Fetch memory tags in the address range @r{[}@var{start address},
+@var{start address} + @var{length}@r{)}.  The target is responsible for
+calculating how many tags will be returned, as this is architecture-specific.
+
+@var{start address} is the starting address of the memory range.
+
+@var{length} is the length, in bytes, of the memory range.
+
+Reply:
+@table @samp
+@item @var{mXX}@dots{}
+Hex encoded sequence of uninterpreted bytes representing the tags found in
+the request memory range.
+
+@item E @var{nn}
+An error occured.  This means that fetching of memory tags failed for some
+reason.
+
+@item @w{}
+An empty reply indicates that @samp{qMemTags} is not supported by the stub,
+although this should not happen given @value{GDBN} will only send this packet
+if the stub has advertised support for memory tagging via @samp{qSupported}.
+@end table
+
+@item QMemTags:@var{start address}:@var{length}:@var{tag bytes}
+@cindex store memory tags
+@cindex @samp{QMemTags} packet
+Store memory tags to the address range @r{[}@var{start address},
+@var{start address} + @var{length}@r{)}.  The target is responsible for
+interpreting the tag bytes and modifying the memory tag granules
+accordingly, given this is architecture-specific.
+
+The interpretation of how many tags should be written to how many memory tag
+granules is also architecture-specific.  The behavior is
+implementation-specific, but the following is suggested.
+
+If the number of memory tags, @var{N}, is greater than or equal to the number
+of memory tag granules, @var{G}, only @var{G} tags will be stored.
+
+If @var{N} is less than @var{G}, the behavior is that of a fill operation,
+and the tag bytes will be used as a pattern that will get repeated until
+@var{G} tags are stored.
+
+@var{start address} is the starting address of the memory range.  The address
+does not have any restriction on alignment or size.
+
+@var{length} is the length, in bytes, of the memory range.
+
+@var{tag bytes} is a sequence of hex encoded uninterpreted bytes which will be
+interpreted by the target.  Each pair of hex digits is interpreted as a
+single byte.
+
+Reply:
+@table @samp
+@item OK
+The request was successful and the memory tag granules were modified
+accordingly.
+
+@item E @var{nn}
+An error occured.  This means that modifying the memory tag granules failed
+for some reason.
+
+@item @w{}
+An empty reply indicates that @samp{QMemTags} is not supported by the stub,
+although this should not happen given @value{GDBN} will only send this packet
+if the stub has advertised support for memory tagging via @samp{qSupported}.
+@end table
+
 @item qOffsets
 @cindex section offsets, remote request
 @cindex @samp{qOffsets} packet
@@ -41321,6 +41392,11 @@ These are the currently defined stub features and their properties:
 @tab @samp{-}
 @tab No
 
+@item @samp{memory-tagging}
+@tab No
+@tab @samp{-}
+@tab No
+
 @end multitable
 
 These are the currently defined stub features, in more detail:
@@ -41535,6 +41611,14 @@ The remote stub understands the @samp{QThreadEvents} packet.
 @item no-resumed
 The remote stub reports the @samp{N} stop reply.
 
+@item memory-tagging
+The remote stub supports and implements the required memory tagging
+functionality and understands the @samp{qMemTags} and @samp{QMemTags} packets.
+
+For AArch64 GNU/Linux systems, this feature also requires access to the smaps
+file in the proc filesystem so memory mapping page flags can be inspected.  This
+is done via the @samp{vFile} requests.
+
 @end table
 
 @item qSymbol::
-- 
2.17.1



  parent reply	other threads:[~2020-07-15 19:47 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-15 19:44 [PATCH 00/23] Memory Tagging Support + AArch64 Linux implementation Luis Machado
2020-07-15 19:44 ` [PATCH 01/23] New target methods for memory tagging support Luis Machado
2020-07-15 19:44 ` [PATCH 02/23] New gdbarch memory tagging hooks Luis Machado
2020-07-15 19:44 ` [PATCH 03/23] Add GDB-side remote target support for memory tagging Luis Machado
2020-07-15 19:44 ` [PATCH 04/23] Unit testing for GDB-side remote memory tagging handling Luis Machado
2020-07-15 19:44 ` [PATCH 05/23] GDBserver remote packet support for memory tagging Luis Machado
2020-07-15 19:44 ` [PATCH 06/23] Unit tests for gdbserver memory tagging remote packets Luis Machado
2020-07-15 19:44 ` Luis Machado [this message]
2020-07-17  5:54   ` [PATCH 07/23] Documentation for " Eli Zaretskii
2020-07-17 14:20     ` Luis Machado
2020-07-15 19:44 ` [PATCH 08/23] AArch64: Add MTE CPU feature check support Luis Machado
2020-07-15 19:44 ` [PATCH 09/23] AArch64: Add target description/feature for MTE registers Luis Machado
2020-07-15 19:45 ` [PATCH 10/23] AArch64: Add MTE register set support for GDB and gdbserver Luis Machado
2020-07-15 19:45 ` [PATCH 11/23] AArch64: Add MTE ptrace requests Luis Machado
2020-07-15 19:45 ` [PATCH 12/23] AArch64: Implement memory tagging target methods for AArch64 Luis Machado
2020-07-15 19:45 ` [PATCH 13/23] Refactor parsing of /proc/<pid>/smaps Luis Machado
2020-07-15 19:45 ` [PATCH 14/23] AArch64: Implement the memory tagging gdbarch hooks Luis Machado
2020-07-15 19:45 ` [PATCH 15/23] AArch64: Add unit testing for logical tag set/get operations Luis Machado
2020-07-15 19:45 ` [PATCH 16/23] AArch64: Report tag violation error information Luis Machado
2020-07-15 19:45 ` [PATCH 17/23] AArch64: Add gdbserver MTE support Luis Machado
2020-07-15 19:45 ` [PATCH 18/23] New mtag commands Luis Machado
2020-07-15 19:45 ` [PATCH 19/23] Documentation for the new " Luis Machado
2020-07-17  6:11   ` Eli Zaretskii
2020-07-17 14:20     ` Luis Machado
2020-07-17 14:29       ` Eli Zaretskii
2020-07-17 15:08         ` Luis Machado
2020-07-15 19:45 ` [PATCH 20/23] Extend "x" and "print" commands to support memory tagging Luis Machado
2020-07-15 19:45 ` [PATCH 21/23] Document new "x" and "print" memory tagging extensions Luis Machado
2020-07-17  6:16   ` Eli Zaretskii
2020-07-17 14:20     ` Luis Machado
2020-07-17 14:31       ` Eli Zaretskii
2020-07-15 19:45 ` [PATCH 22/23] Add NEWS entry Luis Machado
2020-07-17  6:18   ` Eli Zaretskii
2020-07-17 14:20     ` Luis Machado
2020-07-15 19:45 ` [PATCH 23/23] Add memory tagging testcases Luis Machado
2020-07-16 16:49 ` [PATCH 00/23] Memory Tagging Support + AArch64 Linux implementation Alan Hayward
2020-07-17 12:33   ` Luis Machado
2020-07-17 22:02 ` John Baldwin
2020-07-23 13:59   ` Luis Machado
2020-07-23 16:48     ` John Baldwin
2020-07-24 16:10       ` David Spickett
2020-07-23 14:59 ` Luis Machado

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=20200715194513.16641-8-luis.machado@linaro.org \
    --to=luis.machado@linaro.org \
    --cc=Alan.Hayward@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=david.spickett@linaro.org \
    --cc=gdb-patches@sourceware.org \
    --cc=jose.marchesi@oracle.com \
    --cc=omair.javaid@linaro.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: link
Be 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