Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
To: Luis Machado <luis.machado@linaro.org>, gdb-patches@sourceware.org
Cc: david.spickett@linaro.org
Subject: Re: [PATCH v3 13/24] Refactor parsing of /proc/<pid>/smaps
Date: Sat, 26 Dec 2020 01:36:52 -0500	[thread overview]
Message-ID: <e5ba29f7-1ef2-58d4-0e7a-afa19c4ed25f@polymtl.ca> (raw)
In-Reply-To: <20201109170435.15766-14-luis.machado@linaro.org>



On 2020-11-09 12:04 p.m., Luis Machado via Gdb-patches wrote:
> The Linux kernel exposes the information about MTE-protected pages via the
> proc filesystem, more specifically through the smaps file.
> 
> What we're looking for is a mapping with the 'mt' flag, which tells us that
> mapping was created with a PROT_MTE flag and, thus, is capable of using memory
> tagging.
> 
> We already parse that file for other purposes (core file
> generation/filtering), so this patch refactors the code to make the parsing
> of the smaps file reusable for memory tagging.
> 
> The function linux_address_in_memtag_page uses the refactored code to allow
> querying for memory tag support in a particular address, and it gets used in the
> next patch.
> 
> gdb/ChangeLog:
> 
> YYYY-MM-DD  Luis Machado  <luis.machado@linaro.org>
> 
> 	* linux-tdep.c (struct smaps_vmflags) <memory_tagging>: New flag
> 	bit.
> 	(struct smaps_data): New struct.
> 	(decode_vmflags): Handle the 'mt' flag.
> 	(parse_smaps_data): New function, refactored from
> 	linux_find_memory_regions_full.
> 	(linux_address_in_memtag_page): New function.
> 	(linux_find_memory_regions_full): Refactor into parse_smaps_data.
> 	* linux-tdep.h (linux_address_in_memtag_page): New prototype.
> ---
>  gdb/linux-tdep.c | 358 +++++++++++++++++++++++++++++++----------------
>  gdb/linux-tdep.h |   4 +
>  2 files changed, 241 insertions(+), 121 deletions(-)
> 
> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
> index bacb61398f..91bdcc133b 100644
> --- a/gdb/linux-tdep.c
> +++ b/gdb/linux-tdep.c
> @@ -86,8 +86,33 @@ struct smaps_vmflags
>      /* Is this a MAP_SHARED mapping (VM_SHARED, "sh").  */
>  
>      unsigned int shared_mapping : 1;
> +
> +    /* Memory map has memory tagging enabled.  */
> +
> +    unsigned int memory_tagging : 1;
>    };
>  
> +/* Data structure that holds the information contained in the
> +   /proc/<pid>/smaps file.  */
> +
> +struct smaps_data
> +{
> +  ULONGEST start_address;
> +  ULONGEST end_address;
> +  std::string filename;
> +  struct smaps_vmflags vmflags;
> +  bool read;
> +  bool write;
> +  bool exec;
> +  bool priv;
> +  bool has_anonymous;
> +  bool mapping_anon_p;
> +  bool mapping_file_p;
> +
> +  ULONGEST inode;
> +  ULONGEST offset;
> +};
> +
>  /* Whether to take the /proc/PID/coredump_filter into account when
>     generating a corefile.  */
>  
> @@ -472,6 +497,8 @@ decode_vmflags (char *p, struct smaps_vmflags *v)
>  	v->exclude_coredump = 1;
>        else if (strcmp (s, "sh") == 0)
>  	v->shared_mapping = 1;
> +      else if (strcmp (s, "mt") == 0)
> +	v->memory_tagging = 1;
>      }
>  }
>  
> @@ -1267,6 +1294,184 @@ typedef int linux_dump_mapping_p_ftype (filter_flags filterflags,
>  					const char *filename,
>  					ULONGEST addr,
>  					ULONGEST offset);
> +/* Helper function to parse the contents of /proc/<pid>/smaps into a data
> +   structure, for easy access.
> +
> +   DATA is the contents of the smaps file.  The parsed contents are stored
> +   into the SMAPS vector.  */

Add a blank line above this comment.

> +
> +static int
> +parse_smaps_data (const char *data,
> +		  std::vector<struct smaps_data> &smaps,
> +		  const char *mapsfilename)

The return value of that function is unused, it always return 0.  I'd suggest
making it return the std::vector directly.

> +{
> +  char *line, *t;
> +
> +  gdb_assert (data != nullptr);
> +
> +  smaps.clear ();
> +
> +  line = strtok_r ((char *) data, "\n", &t);
> +
> +  while (line != NULL)
> +    {
> +      ULONGEST addr, endaddr, offset, inode;
> +      const char *permissions, *device, *filename;
> +      struct smaps_vmflags v;
> +      size_t permissions_len, device_len;
> +      int read, write, exec, priv;
> +      int has_anonymous = 0;
> +      int mapping_anon_p;
> +      int mapping_file_p;
> +
> +      memset (&v, 0, sizeof (v));
> +      read_mapping (line, &addr, &endaddr, &permissions, &permissions_len,
> +		    &offset, &device, &device_len, &inode, &filename);
> +      mapping_anon_p = mapping_is_anonymous_p (filename);
> +      /* If the mapping is not anonymous, then we can consider it
> +	 to be file-backed.  These two states (anonymous or
> +	 file-backed) seem to be exclusive, but they can actually
> +	 coexist.  For example, if a file-backed mapping has
> +	 "Anonymous:" pages (see more below), then the Linux
> +	 kernel will dump this mapping when the user specified
> +	 that she only wants anonymous mappings in the corefile
> +	 (*even* when she explicitly disabled the dumping of
> +	 file-backed mappings).  */
> +      mapping_file_p = !mapping_anon_p;
> +
> +      /* Decode permissions.  */
> +      read = (memchr (permissions, 'r', permissions_len) != 0);
> +      write = (memchr (permissions, 'w', permissions_len) != 0);
> +      exec = (memchr (permissions, 'x', permissions_len) != 0);
> +      /* 'private' here actually means VM_MAYSHARE, and not
> +	 VM_SHARED.  In order to know if a mapping is really
> +	 private or not, we must check the flag "sh" in the
> +	 VmFlags field.  This is done by decode_vmflags.  However,
> +	 if we are using a Linux kernel released before the commit
> +	 834f82e2aa9a8ede94b17b656329f850c1471514 (3.10), we will
> +	 not have the VmFlags there.  In this case, there is
> +	 really no way to know if we are dealing with VM_SHARED,
> +	 so we just assume that VM_MAYSHARE is enough.  */
> +      priv = memchr (permissions, 'p', permissions_len) != 0;
> +
> +      /* Try to detect if region should be dumped by parsing smaps
> +	 counters.  */
> +      for (line = strtok_r (NULL, "\n", &t);
> +	   line != NULL && line[0] >= 'A' && line[0] <= 'Z';
> +	   line = strtok_r (NULL, "\n", &t))
> +	{
> +	  char keyword[64 + 1];
> +
> +	  if (sscanf (line, "%64s", keyword) != 1)
> +	    {
> +	      warning (_("Error parsing {s,}maps file '%s'"), mapsfilename);
> +	      break;
> +	    }
> +
> +	  if (strcmp (keyword, "Anonymous:") == 0)
> +	    {
> +	      /* Older Linux kernels did not support the
> +		 "Anonymous:" counter.  Check it here.  */
> +	      has_anonymous = 1;
> +	    }
> +	  else if (strcmp (keyword, "VmFlags:") == 0)
> +	    decode_vmflags (line, &v);
> +
> +	  if (strcmp (keyword, "AnonHugePages:") == 0
> +	      || strcmp (keyword, "Anonymous:") == 0)
> +	    {
> +	      unsigned long number;
> +
> +	      if (sscanf (line, "%*s%lu", &number) != 1)
> +		{
> +		  warning (_("Error parsing {s,}maps file '%s' number"),
> +			   mapsfilename);
> +		  break;
> +		}
> +	      if (number > 0)
> +		{
> +		  /* Even if we are dealing with a file-backed
> +		     mapping, if it contains anonymous pages we
> +		     consider it to be *also* an anonymous
> +		     mapping, because this is what the Linux
> +		     kernel does:
> +
> +		     // Dump segments that have been written to.
> +		     if (vma->anon_vma && FILTER(ANON_PRIVATE))
> +		       goto whole;
> +
> +		    Note that if the mapping is already marked as
> +		    file-backed (i.e., mapping_file_p is
> +		    non-zero), then this is a special case, and
> +		    this mapping will be dumped either when the
> +		    user wants to dump file-backed *or* anonymous
> +		    mappings.  */
> +		  mapping_anon_p = 1;
> +		}
> +	    }
> +	}
> +      /* Save the smaps entry to the vector.  */
> +	struct smaps_data map;
> +	std::string fname (filename);

You don't need to create the string here, just do 

  map.filename = filename;

below.

> +
> +	smaps.emplace_back (map);
> +    }
> +
> +  return 0;
> +}
> +
> +/* See linux-tdep.h.  */
> +
> +bool
> +linux_address_in_memtag_page (CORE_ADDR address)
> +{
> +  if (current_inferior ()->fake_pid_p)
> +    return false;> +
> +  pid_t pid = current_inferior ()->pid;
> +
> +  std::string smaps_file = string_printf ("/proc/%d/smaps", pid);
> +
> +  gdb::unique_xmalloc_ptr<char> data
> +    = target_fileio_read_stralloc (NULL, smaps_file.c_str ());
> +
> +  if (data == nullptr)
> +    return false;
> +
> +  std::vector<struct smaps_data> smaps;
> +
> +  /* Parse the contents of smaps into a vector.  */
> +  parse_smaps_data (data.get (), smaps, smaps_file.c_str ());
> +
> +  if (!smaps.empty ())
> +    {

No need for this `if`.

> +      for (struct smaps_data map : smaps)

Iterate by const reference:

  for (const smaps_data &map : smaps)

> +	{
> +	  /* Is the address within [start_address, end_address) in a page
> +	     mapped with memory tagging?  */
> +	  if (address >= map.start_address
> +	      && address < map.end_address
> +	      && map.vmflags.memory_tagging)
> +	    return true;
> +	}
> +    }
> +
> +  return false;
> +}
>  
>  /* List memory regions in the inferior for a corefile.  */
>  
> @@ -1276,8 +1481,7 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
>  				linux_find_memory_region_ftype *func,
>  				void *obfd)
>  {
> -  char mapsfilename[100];
> -  char coredumpfilter_name[100];
> +  std::string coredumpfilter_name;

Declare this on first use (we could push some preparatory patches to change
these to std::string, to make this patch simpler).

>    pid_t pid;
>    /* Default dump behavior of coredump_filter (0x33), according to
>       Documentation/filesystems/proc.txt from the Linux kernel
> @@ -1295,10 +1499,9 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
>  
>    if (use_coredump_filter)
>      {
> -      xsnprintf (coredumpfilter_name, sizeof (coredumpfilter_name),
> -		 "/proc/%d/coredump_filter", pid);
> +      coredumpfilter_name = string_printf ("/proc/%d/coredump_filter", pid);
>        gdb::unique_xmalloc_ptr<char> coredumpfilterdata
> -	= target_fileio_read_stralloc (NULL, coredumpfilter_name);
> +	= target_fileio_read_stralloc (NULL, coredumpfilter_name.c_str ());
>        if (coredumpfilterdata != NULL)
>  	{
>  	  unsigned int flags;
> @@ -1308,125 +1511,39 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
>  	}
>      }
>  
> -  xsnprintf (mapsfilename, sizeof mapsfilename, "/proc/%d/smaps", pid);
> +  std::string mapsfilename = string_printf ("/proc/%d/smaps", pid);
>    gdb::unique_xmalloc_ptr<char> data
> -    = target_fileio_read_stralloc (NULL, mapsfilename);
> +    = target_fileio_read_stralloc (NULL, mapsfilename.c_str ());
>    if (data == NULL)
>      {
>        /* Older Linux kernels did not support /proc/PID/smaps.  */
> -      xsnprintf (mapsfilename, sizeof mapsfilename, "/proc/%d/maps", pid);
> -      data = target_fileio_read_stralloc (NULL, mapsfilename);
> +      mapsfilename = string_printf ("/proc/%d/maps", pid);
> +      data = target_fileio_read_stralloc (NULL, mapsfilename.c_str ());
>      }
>  
> -  if (data != NULL)
> -    {
> -      char *line, *t;
> -
> -      line = strtok_r (data.get (), "\n", &t);
> -      while (line != NULL)
> -	{
> -	  ULONGEST addr, endaddr, offset, inode;
> -	  const char *permissions, *device, *filename;
> -	  struct smaps_vmflags v;
> -	  size_t permissions_len, device_len;
> -	  int read, write, exec, priv;
> -	  int has_anonymous = 0;
> -	  int should_dump_p = 0;
> -	  int mapping_anon_p;
> -	  int mapping_file_p;
> -
> -	  memset (&v, 0, sizeof (v));
> -	  read_mapping (line, &addr, &endaddr, &permissions, &permissions_len,
> -			&offset, &device, &device_len, &inode, &filename);
> -	  mapping_anon_p = mapping_is_anonymous_p (filename);
> -	  /* If the mapping is not anonymous, then we can consider it
> -	     to be file-backed.  These two states (anonymous or
> -	     file-backed) seem to be exclusive, but they can actually
> -	     coexist.  For example, if a file-backed mapping has
> -	     "Anonymous:" pages (see more below), then the Linux
> -	     kernel will dump this mapping when the user specified
> -	     that she only wants anonymous mappings in the corefile
> -	     (*even* when she explicitly disabled the dumping of
> -	     file-backed mappings).  */
> -	  mapping_file_p = !mapping_anon_p;
> -
> -	  /* Decode permissions.  */
> -	  read = (memchr (permissions, 'r', permissions_len) != 0);
> -	  write = (memchr (permissions, 'w', permissions_len) != 0);
> -	  exec = (memchr (permissions, 'x', permissions_len) != 0);
> -	  /* 'private' here actually means VM_MAYSHARE, and not
> -	     VM_SHARED.  In order to know if a mapping is really
> -	     private or not, we must check the flag "sh" in the
> -	     VmFlags field.  This is done by decode_vmflags.  However,
> -	     if we are using a Linux kernel released before the commit
> -	     834f82e2aa9a8ede94b17b656329f850c1471514 (3.10), we will
> -	     not have the VmFlags there.  In this case, there is
> -	     really no way to know if we are dealing with VM_SHARED,
> -	     so we just assume that VM_MAYSHARE is enough.  */
> -	  priv = memchr (permissions, 'p', permissions_len) != 0;
> -
> -	  /* Try to detect if region should be dumped by parsing smaps
> -	     counters.  */
> -	  for (line = strtok_r (NULL, "\n", &t);
> -	       line != NULL && line[0] >= 'A' && line[0] <= 'Z';
> -	       line = strtok_r (NULL, "\n", &t))
> -	    {
> -	      char keyword[64 + 1];
> +  if (data == nullptr)
> +    return 1;
>  
> -	      if (sscanf (line, "%64s", keyword) != 1)
> -		{
> -		  warning (_("Error parsing {s,}maps file '%s'"), mapsfilename);
> -		  break;
> -		}
> +  std::vector<struct smaps_data> smaps;
>  
> -	      if (strcmp (keyword, "Anonymous:") == 0)
> -		{
> -		  /* Older Linux kernels did not support the
> -		     "Anonymous:" counter.  Check it here.  */
> -		  has_anonymous = 1;
> -		}
> -	      else if (strcmp (keyword, "VmFlags:") == 0)
> -		decode_vmflags (line, &v);
> +  /* Parse the contents of smaps into a vector.  */
> +  parse_smaps_data (data.get (), smaps, mapsfilename.c_str ());
>  
> -	      if (strcmp (keyword, "AnonHugePages:") == 0
> -		  || strcmp (keyword, "Anonymous:") == 0)
> -		{
> -		  unsigned long number;
> -
> -		  if (sscanf (line, "%*s%lu", &number) != 1)
> -		    {
> -		      warning (_("Error parsing {s,}maps file '%s' number"),
> -			       mapsfilename);
> -		      break;
> -		    }
> -		  if (number > 0)
> -		    {
> -		      /* Even if we are dealing with a file-backed
> -			 mapping, if it contains anonymous pages we
> -			 consider it to be *also* an anonymous
> -			 mapping, because this is what the Linux
> -			 kernel does:
> -
> -			 // Dump segments that have been written to.
> -			 if (vma->anon_vma && FILTER(ANON_PRIVATE))
> -			 	goto whole;
> -
> -			 Note that if the mapping is already marked as
> -			 file-backed (i.e., mapping_file_p is
> -			 non-zero), then this is a special case, and
> -			 this mapping will be dumped either when the
> -			 user wants to dump file-backed *or* anonymous
> -			 mappings.  */
> -		      mapping_anon_p = 1;
> -		    }
> -		}
> -	    }
> +  if (!smaps.empty ())
> +    {
> +      for (struct smaps_data map : smaps)

Same comments as above.

Simon

  reply	other threads:[~2020-12-26  6:37 UTC|newest]

Thread overview: 96+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 17:04 [PATCH v3 00/24] Memory Tagging Support + AArch64 Linux implementation Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 01/24] New target methods for memory tagging support Luis Machado via Gdb-patches
2020-12-25  4:26   ` Simon Marchi via Gdb-patches
2020-12-28 15:05     ` Luis Machado via Gdb-patches
2020-12-25  5:08   ` Simon Marchi via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 02/24] New gdbarch memory tagging hooks Luis Machado via Gdb-patches
2020-12-25  4:40   ` Simon Marchi via Gdb-patches
2020-12-28 15:44     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 03/24] Add GDB-side remote target support for memory tagging Luis Machado via Gdb-patches
2020-12-25  5:08   ` Simon Marchi via Gdb-patches
2020-12-28 16:28     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 04/24] Unit testing for GDB-side remote memory tagging handling Luis Machado via Gdb-patches
2020-12-25  5:34   ` Simon Marchi via Gdb-patches
2020-12-28 17:17     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 05/24] GDBserver remote packet support for memory tagging Luis Machado via Gdb-patches
2020-12-25  5:50   ` Simon Marchi via Gdb-patches
2020-12-28 17:46     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 06/24] Unit tests for gdbserver memory tagging remote packets Luis Machado via Gdb-patches
2020-12-25 20:13   ` Simon Marchi via Gdb-patches
2020-12-28 18:12     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 07/24] Documentation for " Luis Machado via Gdb-patches
2020-11-09 17:08   ` Eli Zaretskii via Gdb-patches
2020-11-16 15:44     ` David Spickett via Gdb-patches
2020-11-16 16:04       ` David Spickett via Gdb-patches
2020-11-16 17:22         ` Luis Machado via Gdb-patches
2020-11-17 10:05           ` David Spickett via Gdb-patches
2020-11-17 12:01             ` Luis Machado via Gdb-patches
2020-11-17 12:29               ` David Spickett via Gdb-patches
2020-11-17 14:44                 ` Luis Machado via Gdb-patches
2020-11-17 15:16                   ` David Spickett via Gdb-patches
2020-11-17 17:29                     ` Luis Machado via Gdb-patches
2020-11-18 10:39                       ` David Spickett via Gdb-patches
2020-11-18 10:56                         ` Luis Machado via Gdb-patches
2020-11-18 11:22                           ` David Spickett via Gdb-patches
2020-11-16 16:49       ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 08/24] AArch64: Add MTE CPU feature check support Luis Machado via Gdb-patches
2020-12-26  0:04   ` Simon Marchi via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 09/24] AArch64: Add target description/feature for MTE registers Luis Machado via Gdb-patches
2020-12-26  0:10   ` Simon Marchi via Gdb-patches
2020-12-28 18:28     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 10/24] AArch64: Add MTE register set support for GDB and gdbserver Luis Machado via Gdb-patches
2020-12-26  0:17   ` Simon Marchi via Gdb-patches
2020-12-28 18:41     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 11/24] AArch64: Add MTE ptrace requests Luis Machado via Gdb-patches
2020-12-26  0:19   ` Simon Marchi via Gdb-patches
2020-12-28 19:12     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 12/24] AArch64: Implement memory tagging target methods for AArch64 Luis Machado via Gdb-patches
2020-12-26  0:33   ` Simon Marchi via Gdb-patches
2020-12-28 19:50     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 13/24] Refactor parsing of /proc/<pid>/smaps Luis Machado via Gdb-patches
2020-12-26  6:36   ` Simon Marchi via Gdb-patches [this message]
2020-12-29 10:57     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 14/24] AArch64: Implement the memory tagging gdbarch hooks Luis Machado via Gdb-patches
2020-12-26  6:52   ` Simon Marchi via Gdb-patches
2020-12-29 12:16     ` Luis Machado via Gdb-patches
2021-01-18 16:29       ` Simon Marchi via Gdb-patches
2021-01-20 20:01         ` Tom Tromey
2020-11-09 17:04 ` [PATCH v3 15/24] AArch64: Add unit testing for logical tag set/get operations Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 16/24] AArch64: Report tag violation error information Luis Machado via Gdb-patches
2020-11-16 15:43   ` David Spickett via Gdb-patches
2020-11-16 16:45     ` Luis Machado via Gdb-patches
2020-11-17  9:36       ` David Spickett via Gdb-patches
2020-12-26 22:23   ` Simon Marchi via Gdb-patches
2020-12-30  0:50     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 17/24] AArch64: Add gdbserver MTE support Luis Machado via Gdb-patches
2020-12-26 22:30   ` Simon Marchi via Gdb-patches
2020-12-29 14:32     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 18/24] AArch64: Add MTE register set support for core files Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 19/24] New mtag commands Luis Machado via Gdb-patches
2020-12-27  3:32   ` Simon Marchi via Gdb-patches
2020-12-29 17:21     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 20/24] Documentation for the new " Luis Machado via Gdb-patches
2020-11-09 17:11   ` Eli Zaretskii via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 21/24] Extend "x" and "print" commands to support memory tagging Luis Machado via Gdb-patches
2020-11-09 17:14   ` Eli Zaretskii via Gdb-patches
2020-11-09 17:20     ` Luis Machado via Gdb-patches
2020-12-27  4:18   ` Simon Marchi via Gdb-patches
2020-12-29 18:50     ` Luis Machado via Gdb-patches
2021-01-18 17:56       ` Simon Marchi via Gdb-patches
2021-01-18 20:20         ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 22/24] Document new "x" and "print" memory tagging extensions Luis Machado via Gdb-patches
2020-11-09 17:16   ` Eli Zaretskii via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 23/24] Add NEWS entry Luis Machado via Gdb-patches
2020-11-09 17:19   ` Eli Zaretskii via Gdb-patches
2020-11-09 17:22     ` Luis Machado via Gdb-patches
2020-11-09 17:04 ` [PATCH v3 24/24] Add memory tagging testcases Luis Machado via Gdb-patches
2020-11-16 15:47   ` David Spickett via Gdb-patches
2020-11-16 16:51     ` Luis Machado via Gdb-patches
2020-12-27  4:36   ` Simon Marchi via Gdb-patches
2020-12-29 19:32     ` Luis Machado via Gdb-patches
2020-11-16 13:48 ` [PATCH v3 00/24] Memory Tagging Support + AArch64 Linux implementation Luis Machado via Gdb-patches
2020-11-16 14:37   ` Alan Hayward via Gdb-patches
2020-11-23 16:08   ` Luis Machado via Gdb-patches
2020-11-30 13:38     ` Luis Machado via Gdb-patches
2020-12-07 13:17       ` Luis Machado via Gdb-patches
2020-12-07 14:17         ` Alan Hayward 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=e5ba29f7-1ef2-58d4-0e7a-afa19c4ed25f@polymtl.ca \
    --to=gdb-patches@sourceware.org \
    --cc=david.spickett@linaro.org \
    --cc=luis.machado@linaro.org \
    --cc=simon.marchi@polymtl.ca \
    /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