public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Luis Machado <luis.machado@linaro.org>, gdb-patches@sourceware.org
Subject: Re: [PATCH v5 14/25] Refactor parsing of /proc/<pid>/smaps
Date: Thu, 4 Feb 2021 22:38:47 -0500	[thread overview]
Message-ID: <d40b4420-5071-bb5b-5875-66b44f106a9e@polymtl.ca> (raw)
In-Reply-To: <20210127202112.2485702-15-luis.machado@linaro.org>

> +/* 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.  */
> +  smaps = parse_smaps_data (data.get (), smaps_file);

Declare and assign the vector directly:

  std::vector<smaps_data> smaps = ...;

> +
> +  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.  */
>  
>  static int
> @@ -1319,137 +1521,50 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
>        /* Older Linux kernels did not support /proc/PID/smaps.  */
>        maps_filename = string_printf ("/proc/%d/maps", pid);
>        data = target_fileio_read_stralloc (NULL, maps_filename.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 (sscanf (line, "%64s", keyword) != 1)
> -		{
> -		  warning (_("Error parsing {s,}maps file '%s'"),
> -			   maps_filename.c_str ());
> -		  break;
> -		}
> +      if (data == nullptr)
> +	return 1;
> +    }
>  
> -	      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);
> +  std::vector<struct smaps_data> smaps;
>  
> -	      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"),
> -			       maps_filename.c_str ());
> -		      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;
> -		    }
> -		}
> -	    }
> +  /* Parse the contents of smaps into a vector.  */
> +  smaps = parse_smaps_data (data.get (), maps_filename.c_str ());

Likewise here.

>  
> -	  if (has_anonymous)
> -	    should_dump_p = should_dump_mapping_p (filterflags, &v, priv,
> -						   mapping_anon_p,
> -						   mapping_file_p,
> -						   filename, addr, offset);
> -	  else
> -	    {
> -	      /* Older Linux kernels did not support the "Anonymous:" counter.
> -		 If it is missing, we can't be sure - dump all the pages.  */
> -	      should_dump_p = 1;
> -	    }
> +  for (const struct smaps_data map : smaps)

You are missing the & to make it a reference (otherwise it makes a copy
of each item as it iterates, I don't think you want that.

Otherwise, LGTM.

Simon

  reply	other threads:[~2021-02-05  3:38 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-27 20:20 [PATCH v5 00/25] Memory Tagging Support + AArch64 Linux implementation Luis Machado
2021-01-27 20:20 ` [PATCH v5 01/25] New target methods for memory tagging support Luis Machado
2021-01-27 23:26   ` Lancelot SIX
2021-01-28 10:02     ` Luis Machado
2021-02-05  2:31   ` Simon Marchi
2021-01-27 20:20 ` [PATCH v5 02/25] New gdbarch memory tagging hooks Luis Machado
2021-02-05  2:38   ` Simon Marchi
2021-02-05  3:58   ` Simon Marchi
2021-01-27 20:20 ` [PATCH v5 03/25] Add GDB-side remote target support for memory tagging Luis Machado
2021-02-05  2:48   ` Simon Marchi
2021-01-27 20:20 ` [PATCH v5 04/25] Unit testing for GDB-side remote memory tagging handling Luis Machado
2021-02-05  2:50   ` Simon Marchi
2021-01-27 20:20 ` [PATCH v5 05/25] GDBserver remote packet support for memory tagging Luis Machado
2021-02-05  2:56   ` Simon Marchi
2021-02-05 12:38     ` Luis Machado
2021-01-27 20:20 ` [PATCH v5 06/25] Unit tests for gdbserver memory tagging remote packets Luis Machado
2021-01-27 20:20 ` [PATCH v5 07/25] Documentation for " Luis Machado
2021-01-28  3:30   ` Eli Zaretskii
2021-01-28  9:58     ` Luis Machado
2021-01-27 20:20 ` [PATCH v5 08/25] AArch64: Add MTE CPU feature check support Luis Machado
2021-02-05  3:05   ` Simon Marchi
2021-01-27 20:20 ` [PATCH v5 09/25] AArch64: Add target description/feature for MTE registers Luis Machado
2021-01-27 20:20 ` [PATCH v5 10/25] AArch64: Add MTE register set support for GDB and gdbserver Luis Machado
2021-01-27 20:20 ` [PATCH v5 11/25] AArch64: Add MTE ptrace requests Luis Machado
2021-02-05  3:13   ` Simon Marchi
2021-01-27 20:20 ` [PATCH v5 12/25] AArch64: Implement memory tagging target methods for AArch64 Luis Machado
2021-02-05  3:30   ` Simon Marchi
2021-01-27 20:21 ` [PATCH v5 13/25] Convert char array to std::string in linux_find_memory_regions_full Luis Machado
2021-02-05  3:32   ` Simon Marchi
2021-01-27 20:21 ` [PATCH v5 14/25] Refactor parsing of /proc/<pid>/smaps Luis Machado
2021-02-05  3:38   ` Simon Marchi [this message]
2021-01-27 20:21 ` [PATCH v5 15/25] AArch64: Implement the memory tagging gdbarch hooks Luis Machado
2021-02-05  4:09   ` Simon Marchi
2021-02-05 14:05     ` Luis Machado
2021-01-27 20:21 ` [PATCH v5 16/25] AArch64: Add unit testing for logical tag set/get operations Luis Machado
2021-01-27 20:21 ` [PATCH v5 17/25] AArch64: Report tag violation error information Luis Machado
2021-02-05  4:22   ` Simon Marchi
2021-02-05 14:59     ` Luis Machado
2021-02-05 16:13       ` Simon Marchi
2021-01-27 20:21 ` [PATCH v5 18/25] AArch64: Add gdbserver MTE support Luis Machado
2021-01-27 20:21 ` [PATCH v5 19/25] AArch64: Add MTE register set support for core files Luis Machado
2021-01-27 20:21 ` [PATCH v5 20/25] New memory-tag commands Luis Machado
2021-02-05  4:49   ` Simon Marchi
2021-02-05  4:52     ` Simon Marchi
2021-02-08 18:59     ` Luis Machado
2021-03-23 21:46       ` Simon Marchi
2021-01-27 20:21 ` [PATCH v5 21/25] Documentation for the new mtag commands Luis Machado
2021-01-28  3:31   ` Eli Zaretskii
2021-02-05  4:50   ` Simon Marchi
2021-01-27 20:21 ` [PATCH v5 22/25] Extend "x" and "print" commands to support memory tagging Luis Machado
2021-02-05  5:02   ` Simon Marchi
2021-01-27 20:21 ` [PATCH v5 23/25] Document new "x" and "print" memory tagging extensions Luis Machado
2021-01-28  3:31   ` Eli Zaretskii
2021-02-05  5:04   ` Simon Marchi
2021-02-08 20:44     ` Luis Machado
2021-01-27 20:21 ` [PATCH v5 24/25] Add NEWS entry Luis Machado
2021-01-28  3:32   ` Eli Zaretskii
2021-02-05  5:06   ` Simon Marchi
2021-02-08 20:44     ` Luis Machado
2021-01-27 20:21 ` [PATCH v5 25/25] Add memory tagging testcases Luis Machado
2021-02-04 14:18 ` [PING] [PATCH v5 00/25] Memory Tagging Support + AArch64 Linux implementation 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=d40b4420-5071-bb5b-5875-66b44f106a9e@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).