Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH v5 12/14] Add new command "maint print core-file-backed-mappings"
Date: Tue, 21 Jul 2020 17:58:30 -0700	[thread overview]
Message-ID: <20200722005832.863276-13-kevinb@redhat.com> (raw)
In-Reply-To: <20200722005832.863276-1-kevinb@redhat.com>

I wrote a read_core_file_mappings method for FreeBSD and then registered
this gdbarch method.  I saw some strange behavior while testing it and
wanted a way to make sure that mappings were being correctly loaded
into corelow.c, so I wrote the new command which is the topic of this
commit.  I think it might be occasionally useful for debugging strange
corefile behavior.

With regard to FreeBSD, my work isn't ready yet.  Unlike Linux,
FreeBSD puts all mappings into its core file note.  And, unlike Linux,
it doesn't dump load segments which occupy no space in the file.  So
my (perhaps naive) implementation of a FreeBSD read_core_file_mappings
didn't work all that well:  I saw more failures in the corefile2.exp
tests than without it.  I think it should be possible to make FreeBSD
work as well as Linux, but it will require doing something with all of
the mappings, not just the file based mappings that I was considering.

In the v4 series, Pedro asked the following:

    I don't understand what this command provides that "info proc
    mappings" doesn't?  Can you give an example of when you'd use this
    command over "info proc mappings" ?

On Linux, "info proc mappings" and "maint print core-file-backed-mappings"
will produce similar, possibly identical, output.  This need not be
the case for other OSes.  E.g. on FreeBSD, had I finished the
implementation, the output from these commands would have been very
different.  The FreeBSD "info proc mappings" command would show
additional (non-file-backed) mappings in addition to at least one
additional field (memory permissions) for each mapping.

As noted earlier, I was seeing some unexpected behavior while working
on the FreeBSD implementation and wanted to be certain that the
mappings were being correctly loaded by corelow.c.  "info proc
mappings" prints the core file mappings, but doesn't tell us anything
about whether they've been loaded by corelow.c This new maintenance
command directly interrogates the data structures and prints the
values found there.

gdb/ChangeLog:

	* corelow.c (gdbcmd.h): Include.
	(core_target::info_proc_mappings): New method.
	(get_current_core_target): New function.
	(maintenance_print_core_file_backed_mappings): New function.
	(_initialize_corelow): Add core-file-backed-mappings to
	"maint print" commands.
---
 gdb/corelow.c | 87 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 87 insertions(+)

diff --git a/gdb/corelow.c b/gdb/corelow.c
index aeddcccc5d..f9648c5b47 100644
--- a/gdb/corelow.c
+++ b/gdb/corelow.c
@@ -47,6 +47,7 @@
 #include "build-id.h"
 #include "gdbsupport/pathstuff.h"
 #include <unordered_map>
+#include "gdbcmd.h"
 
 #ifndef O_LARGEFILE
 #define O_LARGEFILE 0
@@ -113,6 +114,9 @@ class core_target final : public process_stratum_target
 				  const char *human_name,
 				  bool required);
 
+  /* See definition.  */
+  void info_proc_mappings (struct gdbarch *gdbarch);
+
 private: /* per-core data */
 
   /* The core's section table.  Note that these target sections are
@@ -1026,9 +1030,92 @@ core_target::info_proc (const char *args, enum info_proc_what request)
   return true;
 }
 
+/* Get a pointer to the current core target.  If not connected to a
+   core target, return NULL.  */
+
+static core_target *
+get_current_core_target ()
+{
+  target_ops *proc_target = current_inferior ()->process_target ();
+  return dynamic_cast<core_target *> (proc_target);
+}
+
+/* Display file backed mappings from core file.  */
+
+void
+core_target::info_proc_mappings (struct gdbarch *gdbarch)
+{
+  if (m_core_file_mappings.sections != m_core_file_mappings.sections_end)
+    {
+      printf_filtered (_("Mapped address spaces:\n\n"));
+      if (gdbarch_addr_bit (gdbarch) == 32)
+	{
+	  printf_filtered ("\t%10s %10s %10s %10s %s\n",
+			   "Start Addr",
+			   "  End Addr",
+			   "      Size", "    Offset", "objfile");
+	}
+      else
+	{
+	  printf_filtered ("  %18s %18s %10s %10s %s\n",
+			   "Start Addr",
+			   "  End Addr",
+			   "      Size", "    Offset", "objfile");
+	}
+    }
+
+  for (const struct target_section *tsp = m_core_file_mappings.sections;
+       tsp < m_core_file_mappings.sections_end;
+       tsp++)
+    {
+      ULONGEST start = tsp->addr;
+      ULONGEST end = tsp->endaddr;
+      ULONGEST file_ofs = tsp->the_bfd_section->filepos;
+      const char *filename = bfd_get_filename (tsp->the_bfd_section->owner);
+
+      if (gdbarch_addr_bit (gdbarch) == 32)
+	printf_filtered ("\t%10s %10s %10s %10s %s\n",
+			 paddress (gdbarch, start),
+			 paddress (gdbarch, end),
+			 hex_string (end - start),
+			 hex_string (file_ofs),
+			 filename);
+      else
+	printf_filtered ("  %18s %18s %10s %10s %s\n",
+			 paddress (gdbarch, start),
+			 paddress (gdbarch, end),
+			 hex_string (end - start),
+			 hex_string (file_ofs),
+			 filename);
+    }
+}
+
+/* Implement "maintenance print core-file-backed-mappings" command.  
+
+   If mappings are loaded, the results should be similar to the
+   mappings shown by "info proc mappings".  This command is mainly a
+   debugging tool for GDB developers to make sure that the expected
+   mappings are present after loading a core file.  For Linux, the
+   output provided by this command will be very similar (if not
+   identical) to that provided by "info proc mappings".  This is not
+   necessarily the case for other OSes which might provide
+   more/different information in the "info proc mappings" output.  */
+
+static void
+maintenance_print_core_file_backed_mappings (const char *args, int from_tty)
+{
+  core_target *targ = get_current_core_target ();
+  if (targ != nullptr)
+    targ->info_proc_mappings (targ->core_gdbarch ());
+}
+
 void _initialize_corelow ();
 void
 _initialize_corelow ()
 {
   add_target (core_target_info, core_target_open, filename_completer);
+  add_cmd ("core-file-backed-mappings", class_maintenance,
+           maintenance_print_core_file_backed_mappings,
+	   _("Print core file's file-backed mappings"),
+	   &maintenanceprintlist);
 }
-- 
2.26.2



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

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22  0:58 [PATCH v5 00/14] Fix BZ 25631 - core file memory access problem Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 01/14] Remove hack for GDB which sets the section size to 0 Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 02/14] Adjust corefile.exp test to show regression after bfd hack removal Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 03/14] section_table_xfer_memory: Replace section name with callback predicate Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 04/14] Provide access to non SEC_HAS_CONTENTS core file sections Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 05/14] Test ability to access unwritten-to mmap data in core file Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 06/14] Update binary_get_section_contents to seek using section's file position Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 07/14] Add new gdbarch method, read_core_file_mappings Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 08/14] Use NT_FILE note section for reading core target memory Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 09/14] Add test for accessing read-only mmapped data in a core file Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 10/14] gcore command: Place all file-backed mappings in NT_FILE note Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 11/14] Adjust coredump-filter.exp to account for NT_FILE note handling Kevin Buettner
2020-07-22 18:56   ` Pedro Alves
2020-07-22  0:58 ` Kevin Buettner [this message]
2020-07-23 13:08   ` [PATCH v5 12/14] Add new command "maint print core-file-backed-mappings" Tom de Vries
2020-07-23 20:47     ` Kevin Buettner
2020-07-22  0:58 ` [PATCH v5 13/14] Add documentation for " Kevin Buettner
2020-07-22  2:27   ` Eli Zaretskii
2020-07-22  0:58 ` [PATCH v5 14/14] New core file tests with mappings over existing program memory Kevin Buettner
2020-07-22 18:58 ` [PATCH v5 00/14] Fix BZ 25631 - core file memory access problem Pedro Alves
2020-07-22 20:14   ` Kevin Buettner
2020-07-22 22:40 ` Luis Machado
2020-07-23  3:49   ` Kevin Buettner
2020-07-23 10:37     ` Luis Machado
2020-07-23 21:44       ` Kevin Buettner

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=20200722005832.863276-13-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