+/* Helper function to decode the "VmFlags" field in /proc/PID/smaps.
+
+ This function was based on the documentation found on
+ <Documentation/filesystems/proc.txt>, on the Linux kernel.
+
+ Linux kernels before commit
+ 834f82e2aa9a8ede94b17b656329f850c1471514 (3.10) do not have this
+ field on smaps. */
+
+static void
+decode_vmflags (char *p, struct smaps_vmflags *v)
+{
+ char *saveptr = NULL;
+ const char *s;
+
+ v->initialized_p = 1;
+ p = skip_to_space (p);
+ p = skip_spaces (p);
+
+ for (s = strtok_r (p, " ", &saveptr);
+ s != NULL;
+ s = strtok_r (NULL, " ", &saveptr))
+ {
+ if (strcmp (s, "io") == 0)
+ v->io_page = 1;
+ else if (strcmp (s, "ht") == 0)
+ v->uses_huge_tlb = 1;
+ else if (strcmp (s, "dd") == 0)
+ v->exclude_coredump = 1;
+ else if (strcmp (s, "sh") == 0)
+ v->shared_mapping = 1;
+ }
+}
+
+/* Return 1 if the memory mapping is anonymous, 0 otherwise.
+
+ FILENAME is the name of the file present in the first line of the
+ memory mapping, in the "/proc/PID/smaps" output. For example, if
+ the first line is:
+
+ 7fd0ca877000-7fd0d0da0000 r--p 00000000 fd:02 2100770 /path/to/file
+
+ Then FILENAME will be "/path/to/file". */
+
+static int
+mapping_is_anonymous_p (const char *filename)
+{
+ static regex_t dev_zero_regex, shmem_file_regex, file_deleted_regex;
+ static int init_regex_p = 0;
+
+ if (!init_regex_p)
+ {
+ struct cleanup *c = make_cleanup (null_cleanup, NULL);
+
+ /* Let's be pessimistic and assume there will be an error while
+ compiling the regex'es. */
+ init_regex_p = -1;
+
+ /* DEV_ZERO_REGEX matches "/dev/zero" filenames (with or
+ without the "(deleted)" string in the end). We know for
+ sure, based on the Linux kernel code, that memory mappings
+ whose associated filename is "/dev/zero" are guaranteed to be
+ MAP_ANONYMOUS. */
+ compile_rx_or_error (&dev_zero_regex, "^/dev/zero\\( (deleted)\\)\\?$",
+ _("Could not compile regex to match /dev/zero "
+ "filename"));
+ /* SHMEM_FILE_REGEX matches "/SYSV%08x" filenames (with or
+ without the "(deleted)" string in the end). These filenames
+ refer to shared memory (shmem), and memory mappings
+ associated with them are MAP_ANONYMOUS as well. */
+ compile_rx_or_error (&shmem_file_regex,
+ "^/\\?SYSV[0-9a-fA-F]\\{8\\}\\( (deleted)\\)\\?$",
+ _("Could not compile regex to match shmem "
+ "filenames"));
+ /* FILE_DELETED_REGEX is a heuristic we use to try to mimic the
+ Linux kernel's 'n_link == 0' code, which is responsible to
+ decide if it is dealing with a 'MAP_SHARED | MAP_ANONYMOUS'
+ mapping. In other words, if FILE_DELETED_REGEX matches, it
+ does not necessarily mean that we are dealing with an
+ anonymous shared mapping. However, there is no easy way to
+ detect this currently, so this is the best approximation we
+ have.
+
+ As a result, GDB will dump readonly pages of deleted
+ executables when using the default value of coredump_filter
+ (0x33), while the Linux kernel will not dump those pages.
+ But we can live with that. */
+ compile_rx_or_error (&file_deleted_regex, " (deleted)$",
+ _("Could not compile regex to match "
+ "'<file> (deleted)'"));
+ /* We will never release these regexes, so just discard the
+ cleanups. */
+ discard_cleanups (c);
+
+ /* If we reached this point, then everything succeeded. */
+ init_regex_p = 1;
+ }
+
+ if (init_regex_p == -1)
+ {
+ const char deleted[] = " (deleted)";
+ size_t del_len = sizeof (deleted) - 1;
+ size_t filename_len = strlen (filename);
+
+ /* There was an error while compiling the regex'es above. In
+ order to try to give some reliable information to the caller,
+ we just try to find the string " (deleted)" in the filename.
+ If we managed to find it, then we assume the mapping is
+ anonymous. */
+ return (filename_len >= del_len
+ && strcmp (filename + filename_len - del_len, deleted) == 0);
+ }
+
+ if (*filename == '\0'
+ || regexec (&dev_zero_regex, filename, 0, NULL, 0) == 0
+ || regexec (&shmem_file_regex, filename, 0, NULL, 0) == 0
+ || regexec (&file_deleted_regex, filename, 0, NULL, 0) == 0)
+ return 1;
+
+ return 0;
+}
+
+/* Return 0 if the memory mapping (which is related to FILTERFLAGS, V,
+ MAYBE_PRIVATE_P, and MAPPING_ANONYMOUS_P) should not be dumped, or
+ greater than 0 if it should.
+
+ In a nutshell, this is the logic that we follow in order to decide
+ if a mapping should be dumped or not.
+
+ - If the mapping is associated to a file whose name ends with
+ " (deleted)", or if the file is "/dev/zero", or if it is
+ "/SYSV%08x" (shared memory), or if there is no file associated
+ with it, or if the AnonHugePages: or the Anonymous: fields in the
+ /proc/PID/smaps have contents, then GDB considers this mapping to
+ be anonymous. Otherwise, GDB considers this mapping to be a
+ file-backed mapping (because there will be a file associated with
+ it).
+
+ It is worth mentioning that, from all those checks described
+ above, the most fragile is the one to see if the file name ends
+ with " (deleted)". This does not necessarily mean that the
+ mapping is anonymous, because the deleted file associated with
+ the mapping may have been a hard link to another file, for
+ example. The Linux kernel checks to see if "i_nlink == 0", but
+ GDB cannot easily (and normally) do this check (iff running as
+ root, it could find the mapping in /proc/PID/map_files/ and
+ determine whether there still are other hard links to the
+ inode/file). Therefore, we made a compromise here, and we assume
+ that if the file name ends with " (deleted)", then the mapping is
+ indeed anonymous. FWIW, this is something the Linux kernel could
+ do better: expose this information in a more direct way.
+
+ - If we see the flag "sh" in the "VmFlags:" field (in
+ /proc/PID/smaps), then certainly the memory mapping is shared
+ (VM_SHARED). If we have access to the VmFlags, and we don't see
+ the "sh" there, then certainly the mapping is private. However,
+ Linux kernels before commit
+ 834f82e2aa9a8ede94b17b656329f850c1471514 (3.10) do not have the
+ "VmFlags:" field; in that case, we use another heuristic: if we
+ see 'p' in the permission flags, then we assume that the mapping
+ is private, even though the presence of the 's' flag there would
+ mean VM_MAYSHARE, which means the mapping could still be private.
+ This should work OK enough, however. */
+
+static int
+dump_mapping_p (filter_flags filterflags, const struct smaps_vmflags *v,
+ int maybe_private_p, int mapping_anon_p, int mapping_file_p,
+ const char *filename)
+{
+ /* Initially, we trust in what we received from our caller. This
+ value may not be very precise (i.e., it was probably gathered
+ from the permission line in the /proc/PID/smaps list, which
+ actually refers to VM_MAYSHARE, and not VM_SHARED), but it is
+ what we have until we take a look at the "VmFlags:" field
+ (assuming that the version of the Linux kernel being used
+ supports it, of course). */
+ int private_p = maybe_private_p;
+
+ /* We always dump vDSO and vsyscall mappings, because it's likely that
+ there'll be no file to read the contents from at core load time.
+ The kernel does the same. */
+ if (strcmp ("[vdso]", filename) == 0
+ || strcmp ("[vsyscall]", filename) == 0)
+ return 1;
+
+ if (v->initialized_p)
+ {
+ /* We never dump I/O mappings. */
+ if (v->io_page)
+ return 0;
+
+ /* Check if we should exclude this mapping. */
+ if (v->exclude_coredump)
+ return 0;
+
+ /* Update our notion of whether this mapping is shared or
+ private based on a trustworthy value. */
+ private_p = !v->shared_mapping;
+
+ /* HugeTLB checking. */
+ if (v->uses_huge_tlb)
+ {
+ if ((private_p && (filterflags & COREFILTER_HUGETLB_PRIVATE))
+ || (!private_p && (filterflags & COREFILTER_HUGETLB_SHARED)))
+ return 1;
+
+ return 0;
+ }
+ }
+
+ if (private_p)
+ {
+ if (mapping_anon_p && mapping_file_p)
+ {
+ /* This is a special situation. It can happen when we see a
+ mapping that is file-backed, but that contains anonymous
+ pages. */
+ return ((filterflags & COREFILTER_ANON_PRIVATE) != 0
+ || (filterflags & COREFILTER_MAPPED_PRIVATE) != 0);
+ }
+ else if (mapping_anon_p)
+ return (filterflags & COREFILTER_ANON_PRIVATE) != 0;
+ else
+ return (filterflags & COREFILTER_MAPPED_PRIVATE) != 0;
+ }
+ else
+ {
+ if (mapping_anon_p && mapping_file_p)
+ {
+ /* This is a special situation. It can happen when we see a
+ mapping that is file-backed, but that contains anonymous
+ pages. */
+ return ((filterflags & COREFILTER_ANON_SHARED) != 0
+ || (filterflags & COREFILTER_MAPPED_SHARED) != 0);
+ }
+ else if (mapping_anon_p)
+ return (filterflags & COREFILTER_ANON_SHARED) != 0;
+ else
+ return (filterflags & COREFILTER_MAPPED_SHARED) != 0;
+ }
+}
+