[PATCH 00/23] Memory Tagging Support + AArch64 Linux implementation

[John Baldwin]

On 7/15/20 12:44 PM, Luis Machado via Gdb-patches wrote:
> This patch series implements general memory tagging support for GDB, as well
> as an implementation for AArch64 Linux.
> 
> Memory tagging improves memory safety by tagging various parts of memory and
> raising exceptions when the allocation tag (the one associated with a range of
> memory addresses) does not match the logical tag contained in a pointer that is
> used to access the memory area.
> 
> We already have an implementation of such a mechanism for sparc64 (ADI), but
> it is target-specific and not exposed to the rest of GDB. This series aims to
> make the infrastructure available to other targets that may wish to support
> their specific memory tagging approaches. For AArch64 Linux this is called
> MTE (Memory Tagging Extensions).
> 
> The series is split into a set that deals with generic changes to GDB's
> infrastructure (target methods, gdbarch hooks and remote packets), a set that
> implements support for AArch64 Linux and one last set that implements new
> commands, updates the documentation and adds tests.
> 
> The goal is to make it so the architecture independent parts of GDB don't
> need to interpret tag formats, given the formats are likely different
> for each architecture.  For this reason, GDB will handle tags as a sequence of
> bytes and will not assume a particular format.
> 
> The architecture-specific code can handle the sequence of bytes appropriately.

I only have a couple of thoughts but think this is fine overall.

- For patch 2, I'm not sure the address needs to be a 'struct value' as opposed
  to just being a CORE_ADDR?  The earlier reference I had made to storing tags
  with a value was more about having a way to bundle a tag together with the
  "normal" value at a given memory location, but not using a value to describe
  the address of a tag.

- One thing I do see is that this currently assumes only a single memory tag
  type for a given architecture, but there may be architectures in the future
  which have multiple types of tags.  For APIs we can always add that later
  if needed, but retroactively adding it to the remote protocol might prove
  more sticky.  One alternative might be to do something like

  qMemTags:<type>:<address>:<length>

  and similarly for QMemTags.

  For MTE <type> could be "MTE" or "mte".  In the case that an architecture
  provides multiple tag types, then <type> could be used to disambiguate.

- It might be better to not refer to tags specifically as "allocation tags"
  in the generic code like gdbarch.*.  I do think the 'mtag' commands are
  also still a bit MTE-specific, but that is probably fine for now.

- p/x is very nice

- Very orthogonal: in a branch I have a change to make
  gdbarch_handle_segmentation_fault more generic so it is not specific to
  SIGSEGV but is instead able to report information for any signal.  I
  will try to extract that as a separate RFC.

-- 
John Baldwin