From: Eli Zaretskii <eliz@gnu.org>
To: Luis Machado <luis.machado@linaro.org>
Cc: gdb-patches@sourceware.org, Alan.Hayward@arm.com,
catalin.marinas@arm.com, david.spickett@linaro.org
Subject: Re: [PATCH 19/23] Documentation for the new mtag commands
Date: Fri, 17 Jul 2020 09:11:01 +0300 [thread overview]
Message-ID: <83imemk6x6.fsf@gnu.org> (raw)
In-Reply-To: <20200715194513.16641-20-luis.machado@linaro.org> (message from Luis Machado via Gdb-patches on Wed, 15 Jul 2020 16:45:09 -0300)
> Date: Wed, 15 Jul 2020 16:45:09 -0300
> From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
> Cc: catalin.marinas@arm.com, david.spickett@linaro.org
>
> * gdb.textinfo (Memory Tagging): New subsection.
> (AArch64 Memory Tagging Extension): New subsection.
gdb.texinfo (without the "t"). Also, we usually combine functions and
sections that have the same change description, as in
* gdb.texinfo (Memory Tagging, AArch64 Memory Tagging Extension):
New subsections.
> +Memory tagging is a memory protection technology that validates accesses
> +through pointers via a tag.
The "via a tag" part is ambiguous: it is not clear whether it refers
to the access or to the protection. Suggest a slight rewording:
Memory tagging is a memory protection technology that uses tags to
validate memory accesses through pointers.
> Both the pointer tag and the memory tag in the
> +physical address space must match for the memory access to be validated.
Here, it is unclear what should match what. Do you mean that the
pointer tag must match the memory tag? or do you mean something else?
If the former, then where does the "physical address space" part come
into the picture?
> +There are two types of tags: logical and allocation. The logical tag is
^^^^^^^^^^^^^^^
"A logical tag"
> +stored in the pointers themselves. The allocation tag is the tag associated
^^^^^^^^^^^^^^^^^^
Ditto.
> +with the physical address space, against which the logical tags from pointers
> +are validated.
"Validated" or "compared"? The latter is much less vague, so if it's
accurate, I think we should prefer it.
> +If the underlying architecture supports memory tagging, like AArch64,
^^^^^^^^^^^^
"like AArch64 does"
> +@item mtag showltag @var{address_expression}
> +Show the logical tag contained in the pointer resulting from evaluating the
> +argument expression.
This is slightly better, IMO:
Show the logical tag stored at the address given by
@var{address_expression}.
It avoids two words in a row that end in "ing", which makes it a
mouthful.
> +@item mtag setltag @var{address_expression} @var{tag_bytes}
> +Print the resulting pointer from evaluating the argument expression with a
> +logical tag of @var{tag_bytes}.
I don't understand what "print the resulting point" means in this
context, and the sentence confused me, perhaps for this very reason.
can you elaborate what this means?
> +@item mtag showatag @var{address_expression}
> +Show the allocation tag from the memory address pointed to by the evaluation
> +of the argument expression.
See above: I'd rephrase this similarly to showltag.
> +@item mtag setatag @var{starting_address} @var{length} @var{tag_bytes}
> +Set the allocation tag for memory range @r{[}@var{starting_address},
> +@var{starting_address} + @var{length}@r{)} to @var{tag_bytes}.
So setatag _sets_ a tag, but setltag _prints_ something? Isn't that
inconsistent?
> +@item mtag check @var{address_expression}
> +Given the pointer resulting from evaluating the argument expression, check that
> +the logical tag and the allocation tags match.
Which logical tag and which allocation tag are being tested for a
match here?
> +When @value{GDBN} is debugging the AArch64 architecture, the program is
> +using the v8.5-A feature Memory Tagging Extension (MTE) and there is support
> +in the kernel for MTE, @value{GDBN} will make memory tagging functionality
> +available for inspection and editing of logical and allocation tags.
Please add here a cross-reference to "Memory Tagging" subsection.
> +To aid debugging, @value{GDBN} will output additional information when SIGSEGV
> +signals are generated as a result of memory tag failures.
Can you add some minimal description of the additional information?
> +A new register, @code{tag_ctl}, is made available through the
In what sense is this register "new"? Perhaps you mean "special"?
Thanks.
next prev parent reply other threads:[~2020-07-17 6:11 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 ` [PATCH 07/23] Documentation for " Luis Machado
2020-07-17 5:54 ` 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 [this message]
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=83imemk6x6.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=Alan.Hayward@arm.com \
--cc=catalin.marinas@arm.com \
--cc=david.spickett@linaro.org \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@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