Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Luis Machado via Gdb-patches <gdb-patches@sourceware.org>
To: Simon Marchi <simon.marchi@polymtl.ca>, gdb-patches@sourceware.org
Cc: david.spickett@linaro.org
Subject: Re: [PATCH v3 13/24] Refactor parsing of /proc/<pid>/smaps
Date: Tue, 29 Dec 2020 07:57:53 -0300	[thread overview]
Message-ID: <b709c687-f563-19b6-b81e-891ebb4fbcf2@linaro.org> (raw)
In-Reply-To: <e5ba29f7-1ef2-58d4-0e7a-afa19c4ed25f@polymtl.ca>

On 12/26/20 3:36 AM, Simon Marchi wrote:
> 
> 
> 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.
> 

Fixed.

>> +
>> +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.
> 

There has been some changes to this function. I recall it returning 1 as 
well. I've changed it as suggested. It makes it simpler.

>> +{
>> +  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.
> 

Fixed.

>> +
>> +	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)
> 

Fixed now.

>> +	{
>> +	  /* 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).
> 

Yeah. That looks like it will benefit from a cleanup. I'll do as a 
separate patch.

>>     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
> 

Fixed. Thanks.

  reply	other threads:[~2020-12-29 10:58 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
2020-12-29 10:57     ` Luis Machado via Gdb-patches [this message]
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=b709c687-f563-19b6-b81e-891ebb4fbcf2@linaro.org \
    --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