Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
To: Alan Hayward <Alan.Hayward@arm.com>
Cc: "david.spickett@linaro.org" <david.spickett@linaro.org>,
	nd <nd@arm.com>,
	"gdb-patches\\@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH v2 12/24] AArch64: Implement memory tagging target methods for AArch64
Date: Thu, 29 Oct 2020 11:45:01 -0300	[thread overview]
Message-ID: <0fdae06b-0a05-3609-07fd-fa89d1bc79a4@linaro.org> (raw)
In-Reply-To: <56baf1d1-2bdd-f921-9f35-2ed209504cf4@linaro.org>

On 10/29/20 11:39 AM, Luis Machado wrote:
> On 10/29/20 11:21 AM, Alan Hayward wrote:
>>
>>
>>> On 22 Oct 2020, at 21:00, Luis Machado <luis.machado@linaro.org> wrote:
>>>
>>> Updates on v2:
>>>
>>> - Added type parameter to the target method implementations.
>>>
>>> -- 
>>>
>>> The patch implements the memory tagging target hooks for AArch64, so we
>>> can handle MTE.
>>>
>>> gdb/ChangeLog:
>>>
>>> YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>
>>>
>>>     * Makefile.in (ALL_64_TARGET_OBS): Add arch/aarch64-mte-linux.o.
>>>     (HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h and
>>>     nat/aarch64-mte-linux-ptrace.h.
>>>     * aarch64-linux-nat.c: Include nat/aarch64-mte-linux-ptrace.h.
>>>     (aarch64_linux_nat_target) <supports_memory_tagging>: New method
>>>     override.
>>>     <fetch_memtags>: New method override.
>>>     <store_memtags>: New method override.
>>>     (aarch64_linux_nat_target::supports_memory_tagging): New method.
>>>     (aarch64_linux_nat_target::fetch_memtags): New method.
>>>     (aarch64_linux_nat_target::store_memtags): New method.
>>>     * arch/aarch64-mte-linux.c: New file.
>>>     * arch/aarch64-mte-linux.h: Include gdbsupport/common-defs.h.
>>>     (MTE_GRANULE_SIZE): Define.
>>>     (get_tag_granules): New prototype.
>>>     * configure.nat (NATDEPFILES): Add nat/aarch64-mte-linux-ptrace.o.
>>>     * configure.tgt (aarch64*-*-linux*): Add arch/aarch64-mte-linux.o.
>>>     * nat/aarch64-mte-linux-ptrace.c: New file.
>>>     * nat/aarch64-mte-linux-ptrace.h: New file.
>>> ---
>>> gdb/Makefile.in                    |   1 +
>>> gdb/aarch64-linux-nat.c            |  50 ++++++++
>>> gdb/arch/aarch64-mte-linux.c       |  34 +++++
>>> gdb/arch/aarch64-mte-linux.h       |  10 ++
>>> gdb/configure.nat                  |   3 +-
>>> gdb/configure.tgt                  |   1 +
>>> gdb/nat/aarch64-mte-linux-ptrace.c | 200 +++++++++++++++++++++++++++++
>>> gdb/nat/aarch64-mte-linux-ptrace.h |  17 +++
>>> 8 files changed, 315 insertions(+), 1 deletion(-)
>>> create mode 100644 gdb/arch/aarch64-mte-linux.c
>>> create mode 100644 gdb/nat/aarch64-mte-linux-ptrace.c
>>>
>>> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
>>> index 8c9e6c9f6c..33a08a2288 100644
>>> --- a/gdb/Makefile.in
>>> +++ b/gdb/Makefile.in
>>> @@ -692,6 +692,7 @@ ALL_64_TARGET_OBS = \
>>>     amd64-windows-tdep.o \
>>>     arch/aarch64.o \
>>>     arch/aarch64-insn.o \
>>> +    arch/aarch64-mte-linux.o \
>>>     arch/amd64.o \
>>>     ia64-linux-tdep.o \
>>>     ia64-tdep.o \
>>> diff --git a/gdb/aarch64-linux-nat.c b/gdb/aarch64-linux-nat.c
>>> index dea34da669..4edf5a0454 100644
>>> --- a/gdb/aarch64-linux-nat.c
>>> +++ b/gdb/aarch64-linux-nat.c
>>> @@ -52,6 +52,8 @@
>>>
>>> #include "arch/aarch64-mte-linux.h"
>>>
>>> +#include "nat/aarch64-mte-linux-ptrace.h"
>>> +
>>> #ifndef TRAP_HWBKPT
>>> #define TRAP_HWBKPT 0x0004
>>> #endif
>>> @@ -102,6 +104,16 @@ class aarch64_linux_nat_target final : public 
>>> linux_nat_target
>>>      override;
>>>
>>>    struct gdbarch *thread_architecture (ptid_t) override;
>>> +
>>> +  bool supports_memory_tagging () override;
>>> +
>>> +  /* Read memory allocation tags from memory via PTRACE.  */
>>> +  int fetch_memtags (CORE_ADDR address, size_t len,
>>> +             gdb::byte_vector &tags, int type) override;
>>> +
>>> +  /* Write allocation tags to memory via PTRACE.  */
>>> +  int store_memtags (CORE_ADDR address, size_t len,
>>> +             const gdb::byte_vector &tags, int type) override;
>>> };
>>>
>>> static aarch64_linux_nat_target the_aarch64_linux_nat_target;
>>> @@ -1050,6 +1062,44 @@ aarch64_linux_nat_target::thread_architecture 
>>> (ptid_t ptid)
>>>    return gdbarch_find_by_info (info);
>>> }
>>>
>>> +/* Implement the "supports_memory_tagging" target_ops method.  */
>>> +
>>> +bool
>>> +aarch64_linux_nat_target::supports_memory_tagging ()
>>> +{
>>> +  return (linux_get_hwcap2 (this) & HWCAP2_MTE) != 0;
>>> +}
>>> +
>>> +/* Implement the "fetch_memtags" target_ops method.  */
>>> +
>>> +int
>>> +aarch64_linux_nat_target::fetch_memtags (CORE_ADDR address, size_t len,
>>> +                     gdb::byte_vector &tags, int type)
>>
>> I’m a little unsure as to where the type is coming from. Who in the 
>> call stack
>> is explicitly passing the value 1?
> 
> Someone invoking the target methods directly or invoking the gdbarch 
> hooks. For example, in gdb/printcmd.c:
> 
>    if (gdbarch_set_memtags (target_gdbarch (), val, 0, tags,
>                             tag_logical) != 0)
> 
> Or:
> 
> 
>    std::string tag = gdbarch_memtag_to_string (target_gdbarch (),
>                                                val, tag_type);
> 
> 
> 
>> It’s different from the LOGICAL and ALLOCATION enum values used 
>> elsewhere?
> 
> No. Just a different type (int). The remote layer shouldn't try to 
> interpret these tag types though. It should just forward them to the 
> other side.

Complementing the answer... It isn't the case at the moment, but one of 
the layers of the target could translate the generic enums 
(tag_logical/tag_allocation) to something different.

That's why I don't want the remote target to be aware of what these tag 
types mean.

  reply	other threads:[~2020-10-29 14:45 UTC|newest]

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

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=0fdae06b-0a05-3609-07fd-fa89d1bc79a4@linaro.org \
    --to=gdb-patches@sourceware.org \
    --cc=Alan.Hayward@arm.com \
    --cc=david.spickett@linaro.org \
    --cc=luis.machado@linaro.org \
    --cc=nd@arm.com \
    /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