public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH v4 10/14] gcore command: Place all file-backed mappings in NT_FILE note
Date: Sun,  5 Jul 2020 15:58:03 -0700	[thread overview]
Message-ID: <20200705225807.2264705-11-kevinb@redhat.com> (raw)
In-Reply-To: <20200705225807.2264705-1-kevinb@redhat.com>

When making a core file with the GDB's gcore command on Linux,
the same criteria used for determining which mappings should be
dumped were also being used for determining which entries should
be placed in the NT_FILE note.  This is wrong; we want to place
all file-backed mappings in this note.

The predicate function, dump_mapping_p, was used to determine whether
or not to dump a mapping from within linux_find_memory_regions_full.
This commit leaves this predicate in place, but adds a new parameter,
should_dump_mapping_p, to linux_find_memory_regions_full.  It then
calls should_dump_mapping_p instead of dump_mapping_p.  dump_mapping_p
is passed to linux_find_memory_regions_full at one call site; at the
other call site, dump_note_entry_p is passed instead.

gdb/ChangeLog:

	* linux-tdep.c (dump_note_entry_p): New function.
	(linux_dump_mapping_p_ftype): New typedef.
	(linux_find_memory_regions_full): Add new parameter,
	should_dump_mapping_p.
	(linux_find_memory_regions): Adjust call to
	linux_find_memory_regions_full.
	(linux_make_mappings_core_file_notes): Use dump_note_entry_p in
	call to linux_find_memory_regions_full.
---
 gdb/linux-tdep.c | 41 +++++++++++++++++++++++++++++++++++++----
 1 file changed, 37 insertions(+), 4 deletions(-)

diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c
index fa59b09eec..302e432968 100644
--- a/gdb/linux-tdep.c
+++ b/gdb/linux-tdep.c
@@ -726,6 +726,25 @@ dump_mapping_p (filter_flags filterflags, const struct smaps_vmflags *v,
   return dump_p;
 }
 
+/* As above, but return true only when we should dump the NT_FILE
+   entry.  */
+
+static int
+dump_note_entry_p (filter_flags filterflags, const struct smaps_vmflags *v,
+		int maybe_private_p, int mapping_anon_p, int mapping_file_p,
+		const char *filename, ULONGEST addr, ULONGEST offset)
+{
+  /* vDSO and vsyscall mappings will end up in the core file.  Don't
+     put them in the NT_FILE note.  */
+  if (strcmp ("[vdso]", filename) == 0
+      || strcmp ("[vsyscall]", filename) == 0)
+    return 0;
+
+  /* Otherwise, any other file-based mapping should be placed in the
+     note.  */
+  return filename != nullptr;
+}
+
 /* Implement the "info proc" command.  */
 
 static void
@@ -1240,10 +1259,20 @@ typedef int linux_find_memory_region_ftype (ULONGEST vaddr, ULONGEST size,
 					    const char *filename,
 					    void *data);
 
+typedef int linux_dump_mapping_p_ftype (filter_flags filterflags,
+					const struct smaps_vmflags *v,
+					int maybe_private_p,
+					int mapping_anon_p,
+					int mapping_file_p,
+					const char *filename,
+					ULONGEST addr,
+					ULONGEST offset);
+
 /* List memory regions in the inferior for a corefile.  */
 
 static int
 linux_find_memory_regions_full (struct gdbarch *gdbarch,
+				linux_dump_mapping_p_ftype *should_dump_mapping_p,
 				linux_find_memory_region_ftype *func,
 				void *obfd)
 {
@@ -1394,9 +1423,10 @@ linux_find_memory_regions_full (struct gdbarch *gdbarch,
 	    }
 
 	  if (has_anonymous)
-	    should_dump_p = dump_mapping_p (filterflags, &v, priv,
-					    mapping_anon_p, mapping_file_p,
-					    filename, addr, offset);
+	    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.
@@ -1460,6 +1490,7 @@ linux_find_memory_regions (struct gdbarch *gdbarch,
   data.obfd = obfd;
 
   return linux_find_memory_regions_full (gdbarch,
+					 dump_mapping_p,
 					 linux_find_memory_regions_thunk,
 					 &data);
 }
@@ -1543,7 +1574,9 @@ linux_make_mappings_corefile_notes (struct gdbarch *gdbarch, bfd *obfd,
   pack_long (buf, long_type, 1);
   obstack_grow (&data_obstack, buf, TYPE_LENGTH (long_type));
 
-  linux_find_memory_regions_full (gdbarch, linux_make_mappings_callback,
+  linux_find_memory_regions_full (gdbarch, 
+				  dump_note_entry_p,
+				  linux_make_mappings_callback,
 				  &mapping_data);
 
   if (mapping_data.file_count != 0)
-- 
2.26.2


  parent reply	other threads:[~2020-07-05 22:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-05 22:57 [PATCH v4 00/14] Fix BZ 25631 - core file memory access problem Kevin Buettner
2020-07-05 22:57 ` [PATCH v4 01/14] Remove hack for GDB which sets the section size to 0 Kevin Buettner
2020-07-05 22:57 ` [PATCH v4 02/14] Adjust corefile.exp test to show regression after bfd hack removal Kevin Buettner
2020-07-05 22:57 ` [PATCH v4 03/14] section_table_xfer_memory: Replace section name with callback predicate Kevin Buettner
2020-07-05 22:57 ` [PATCH v4 04/14] Provide access to non SEC_HAS_CONTENTS core file sections Kevin Buettner
2020-07-05 22:57 ` [PATCH v4 05/14] Test ability to access unwritten-to mmap data in core file Kevin Buettner
2020-07-05 22:57 ` [PATCH v4 06/14] Update binary_get_section_contents to seek using section's file position Kevin Buettner
2020-07-05 22:58 ` [PATCH v4 07/14] Add new gdbarch method, read_core_file_mappings Kevin Buettner
2020-07-05 22:58 ` [PATCH v4 08/14] Use NT_FILE note section for reading core target memory Kevin Buettner
2020-07-10 20:08   ` Pedro Alves
2020-07-14  7:53     ` Kevin Buettner
2020-07-21 18:21       ` Tom Tromey
2020-07-21  2:09     ` Kevin Buettner
2020-07-05 22:58 ` [PATCH v4 09/14] Add test for accessing read-only mmapped data in a core file Kevin Buettner
2020-07-05 22:58 ` Kevin Buettner [this message]
2020-07-05 22:58 ` [PATCH v4 11/14] xfail gdb.base/coredump-filter.exp test which now works without a binary Kevin Buettner
2020-07-10 20:07   ` Pedro Alves
2020-07-13 11:38     ` Strasuns, Mihails
2020-07-13 17:04       ` Kevin Buettner
2020-07-05 22:58 ` [PATCH v4 12/14] Add new command "maint print core-file-backed-mappings" Kevin Buettner
2020-07-10 20:08   ` Pedro Alves
2020-07-10 20:10     ` Pedro Alves
2020-07-13 17:33     ` Kevin Buettner
2020-07-05 22:58 ` [PATCH v4 13/14] Add documentation for " Kevin Buettner
2020-07-06  2:26   ` Eli Zaretskii
2020-07-05 22:58 ` [PATCH v4 14/14] New core file tests with mappings over existing program memory Kevin Buettner
2020-07-10 20:08   ` Pedro Alves
2020-07-10 20:13 ` [PATCH v4 00/14] Fix BZ 25631 - core file memory access problem Pedro Alves

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=20200705225807.2264705-11-kevinb@redhat.com \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sourceware.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).