gdb/gdb-rhbz2160211-excessive-core-file-warnings.patch

From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
From: Kevin Buettner <kevinb@redhat.com>
Date: Thu, 29 Jun 2023 18:20:30 -0700
Subject: gdb-rhbz2160211-excessive-core-file-warnings.patch

;; Backport two commits, 0ad504dd464 and ea70f941f9b, from Lancelot SIX
;; which prevent repeated warnings from being printed while loading a
;; core file. (RH BZ 2160211)

gdb/corelow.c: avoid repeated warnings in build_file_mappings

When GDB opens a coredump it tries to locate and then open all files
which were mapped in the process.

If a file is found but cannot be opened with BFD (bfd_open /
bfd_check_format fails), then a warning is printed to the user.  If the
same file was mapped multiple times in the process's address space, the
warning is printed once for each time the file was mapped.  I find this
un-necessarily noisy.

This patch makes it so the warning message is printed only once per
file.

There was a comment in the code assuming that if the file was found on
the system, opening it (bfd_open + bfd_check_format) should always
succeed.  A recent change in BFD (014a602b86f "Don't optimise bfd_seek
to same position") showed that this assumption is not valid.  For
example, it is possible to have a core dump of a process which had
mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM).  In
such case the core dump does contain the information that portions of
this special file were mapped in the host process, but trying to seek to
position 0 will fail, making bfd_check_format fail.  This patch removes
this comment.

Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb/corelow.c: do not try to reopen a file if open failed once

In the current implementation, core_target::build_file_mappings will try
to locate and open files which were mapped in the process for which the
core dump was produced.  If the file cannot be found or cannot be
opened, GDB will re-try to open it once for each time it was mapped in
the process's address space.

This patch makes it so GDB recognizes that it has already failed to open
a given file once and does not re-try the process for each mapping.

Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

diff --git a/gdb/corelow.c b/gdb/corelow.c
--- a/gdb/corelow.c
+++ b/gdb/corelow.c
@@ -237,6 +237,16 @@ core_target::build_file_mappings ()
 	   weed out non-file-backed mappings.  */
 	gdb_assert (filename != nullptr);
 
+	if (unavailable_paths.find (filename) != unavailable_paths.end ())
+	  {
+	    /* We have already seen some mapping for FILENAME but failed to
+	       find/open the file.  There is no point in trying the same
+	       thing again so just record that the range [start, end) is
+	       unavailable.  */
+	    m_core_unavailable_mappings.emplace_back (start, end - start);
+	    return;
+	  }
+
 	struct bfd *bfd = bfd_map[filename];
 	if (bfd == nullptr)
 	  {
@@ -254,11 +264,10 @@ core_target::build_file_mappings ()
 	    if (expanded_fname == nullptr)
 	      {
 		m_core_unavailable_mappings.emplace_back (start, end - start);
-		/* Print just one warning per path.  */
-		if (unavailable_paths.insert (filename).second)
-		  warning (_("Can't open file %s during file-backed mapping "
-			     "note processing"),
-			   filename);
+		unavailable_paths.insert (filename);
+		warning (_("Can't open file %s during file-backed mapping "
+			   "note processing"),
+			 filename);
 		return;
 	      }
 
@@ -268,18 +277,11 @@ core_target::build_file_mappings ()
 	    if (bfd == nullptr || !bfd_check_format (bfd, bfd_object))
 	      {
 		m_core_unavailable_mappings.emplace_back (start, end - start);
-		/* If we get here, there's a good chance that it's due to
-		   an internal error.  We issue a warning instead of an
-		   internal error because of the possibility that the
-		   file was removed in between checking for its
-		   existence during the expansion in exec_file_find()
-		   and the calls to bfd_openr() / bfd_check_format(). 
-		   Output both the path from the core file note along
-		   with its expansion to make debugging this problem
-		   easier.  */
+		unavailable_paths.insert (filename);
 		warning (_("Can't open file %s which was expanded to %s "
 			   "during file-backed mapping note processing"),
 			 filename, expanded_fname.get ());
+
 		if (bfd != nullptr)
 		  bfd_close (bfd);
 		return;