public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
* [rpms/gdb] gdb-17.2-rebase-f44: Backport commits to fix gcore failures and fileio.exp failures
@ 2026-06-28  0:02 Kevin Buettner
  0 siblings, 0 replies; only message in thread
From: Kevin Buettner @ 2026-06-28  0:02 UTC (permalink / raw)
  To: git-commits

A new commit has been pushed.

Repo   : rpms/gdb
Branch : gdb-17.2-rebase-f44
Commit : 54912b4e61ebded0ceefb55563acd4faf7799d89
Author : Kevin Buettner <kevinb@redhat.com>
Date   : 2026-02-25T20:07:19-07:00
Stats  : +297/-0 in 6 file(s)
URL    : https://src.fedoraproject.org/rpms/gdb/c/54912b4e61ebded0ceefb55563acd4faf7799d89?branch=gdb-17.2-rebase-f44

Log:
Backport commits to fix gcore failures and fileio.exp failures

---
diff --git a/_gdb.spec.Patch.include b/_gdb.spec.Patch.include
index 3816a26..56bca73 100644
--- a/_gdb.spec.Patch.include
+++ b/_gdb.spec.Patch.include
@@ -41,3 +41,12 @@ Patch007: gdb-rhbz2403580-misplaced-symtabs.patch
 # Can be dropped on a rebase to gdb 17.2 or 18.1
 Patch008: gdb-rhbz2435950-skip-revert.patch
 
+# Backport of upstream commit c1da013915e from Kevin Buettner
+# (RHBZ 2413405).
+Patch009: gdb-rhbz2413405-gcore-unreadable-pages.patch
+
+# Backport of upstream commit d2cc16cd7fc from Jan Vrany fixing
+# FAILs in gdb.base/fileio.exp caused by macro expansion of
+# path components in OUTDIR.gdb/testsuite: fix FAILs in fileio.exp
+Patch010: gdb-fileio-test-fixes.patch
+

diff --git a/_gdb.spec.patch.include b/_gdb.spec.patch.include
index 53b05cc..6295406 100644
--- a/_gdb.spec.patch.include
+++ b/_gdb.spec.patch.include
@@ -6,3 +6,5 @@
 %patch -p1 -P006
 %patch -p1 -P007
 %patch -p1 -P008
+%patch -p1 -P009
+%patch -p1 -P010

diff --git a/_patch_order b/_patch_order
index f318fc5..6fe91da 100644
--- a/_patch_order
+++ b/_patch_order
@@ -6,3 +6,5 @@ gdb-rhbz2424325-c23-more-const-fixes.patch
 gdb-rhbz2424325-c++20-implicit-lambda-capture.patch
 gdb-rhbz2403580-misplaced-symtabs.patch
 gdb-rhbz2435950-skip-revert.patch
+gdb-rhbz2413405-gcore-unreadable-pages.patch
+gdb-fileio-test-fixes.patch

diff --git a/gdb-fileio-test-fixes.patch b/gdb-fileio-test-fixes.patch
new file mode 100644
index 0000000..045cb38
--- /dev/null
+++ b/gdb-fileio-test-fixes.patch
@@ -0,0 +1,89 @@
+From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
+From: Kevin Buettner <kevinb@redhat.com>
+Date: Wed, 25 Feb 2026 20:02:22 -0700
+Subject: gdb-fileio-test-fixes.patch
+
+;; Backport of upstream commit d2cc16cd7fc from Jan Vrany fixing
+;; FAILs in gdb.base/fileio.exp caused by macro expansion of
+;; path components in OUTDIR.gdb/testsuite: fix FAILs in fileio.exp
+
+I'm experiencing intermittent FAILs in fileio.exp when running on (my)
+CI:
+
+    FAIL: gdb.base/fileio.exp: Open a file
+    FAIL: gdb.base/fileio.exp: Creating already existing file returns EEXIST
+    FAIL: gdb.base/fileio.exp: Open for write but no write permission returns EACCES
+    FAIL: gdb.base/fileio.exp: Writing to a file
+    ...
+
+The problem turned out to be the way the OUTDIR gets defined in fileio.c.
+The path is passed down "naked" and turned into string by STRINGIFY macro.
+
+However, if the path happens to contain name of unrelated pre-existing
+C macro, this macro gets expanded during the "stringification", resulting
+in (likely) different path than used in fileio.exp and therefore causing
+failures.
+
+For example, if the GDB is compiled and tested in directory
+
+    /var/lib/jenkins/workspace/binutils-gdb/build/x86_64-linux-gnu
+
+then fileio.c is compiled with
+
+   -DOUTDIR_=/var/lib/jenkins/workspace/binutils-gdb/build/x86_64-linux-gnu/gdb/testsuite/outputs/gdb.base/fileio
+
+But because there's also C macro named "linux" defined to 1, the resulting
+OUTDIR is actually:
+
+   /var/lib/jenkins/workspace/binutils-gdb/build/x86_64-1-gnu/gdb/testsuite/outputs/gdb.base/fileio
+
+This commit fixes this by defining the OUTDIR as string literal in first
+place (similarly to how it was done prior commit cc91060) and updating
+quote_for_host to handle strings that themselves contains quote (").
+
+Tested on x86_64-linux by running all tests using quote_for_host with
+both target board unix and host/target board local-remote-host-native.
+
+Approved-By: Tom Tromey <tom@tromey.com>
+
+diff --git a/gdb/testsuite/gdb.base/fileio.c b/gdb/testsuite/gdb.base/fileio.c
+--- a/gdb/testsuite/gdb.base/fileio.c
++++ b/gdb/testsuite/gdb.base/fileio.c
+@@ -73,10 +73,6 @@ static const char *strerrno (int err);
+ 
+ #define STRING      "Hello World"
+ 
+-#define STRINGIFY(s) STRINGIFY_(s)
+-#define STRINGIFY_(s) #s
+-#define OUTDIR STRINGIFY (OUTDIR_)
+-
+ static void stop (void) {}
+ 
+ /* A NULL string.  We pass this to stat below instead of a NULL
+diff --git a/gdb/testsuite/gdb.base/fileio.exp b/gdb/testsuite/gdb.base/fileio.exp
+--- a/gdb/testsuite/gdb.base/fileio.exp
++++ b/gdb/testsuite/gdb.base/fileio.exp
+@@ -27,7 +27,7 @@ if {[is_remote host]} {
+ 
+ if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
+ 	   executable \
+-	   [list debug additional_flags=[quote_for_host -DOUTDIR_=$outdir/]]] != "" } {
++	   [list debug additional_flags=[quote_for_host -DOUTDIR=\"$outdir/\"]]] != "" } {
+     untested "failed to compile"
+     return -1
+ }
+diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
+--- a/gdb/testsuite/lib/gdb.exp
++++ b/gdb/testsuite/lib/gdb.exp
+@@ -6150,9 +6150,9 @@ proc escape_for_host { str } {
+ proc quote_for_host { args } {
+     set str [join $args]
+     if { [is_remote host] } {
+-	set str [join [list {\"} $str {\"}] ""]
++	set str [join [list {\"} [regsub -all {"} $str {\\\"}] {\"}] ""]
+     } else {
+-	set str [join [list {"} $str {"}] ""]
++	set str [join [list {"} [regsub -all {"} $str {\"}] {"}] ""]
+     }
+     return $str
+ }

diff --git a/gdb-rhbz2413405-gcore-unreadable-pages.patch b/gdb-rhbz2413405-gcore-unreadable-pages.patch
new file mode 100644
index 0000000..9dd5847
--- /dev/null
+++ b/gdb-rhbz2413405-gcore-unreadable-pages.patch
@@ -0,0 +1,188 @@
+From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
+From: Kevin Buettner <kevinb@redhat.com>
+Date: Wed, 25 Feb 2026 19:58:50 -0700
+Subject: gdb-rhbz2413405-gcore-unreadable-pages.patch
+
+;; Backport of upstream commit c1da013915e from Kevin Buettner
+;; (RHBZ 2413405).
+
+gcore: Handle unreadable pages within readable memory regions
+
+GLIBC 2.42 changed how thread stack guard pages are implemented [2].
+In GLIBC 2.41 and earlier, guard pages were set up using mprotect() to
+mark guard regions with no permissions.  Once configured, guard pages
+were visible as separate entries in /proc/PID/maps with no permissions
+(i.e. they're inaccessible).  In GLIBC 2.42, guard pages are
+installed using the kernel's MADV_GUARD_INSTALL mechanism [1], which
+marks them at the page table entry (PTE) level within the existing
+mapping.
+
+As a consequence, guard pages do not appear as separate entries in
+/proc/PID/maps, but remain as part of the containing mapping.  Moreover,
+thread stacks from multiple mmap() calls may be merged into a single
+virtual memory area (VMA) with read and write permissions since there's
+no guard page VMA to separate them.  These guard pages cannot be
+distinguished by examining VMA listings but do return EIO when read
+from /proc/PID/mem.
+
+GDB's gcore code reads /proc/PID/smaps to discover memory regions and
+creates one BFD section per mapping.  (On linux, this is performed in
+linux_find_memory_regions_full in linux-tdep.c.) With the old layout,
+memory areas with guard pages appeared separately with no permissions,
+which were filtered out.  Each thread stack became its own section
+containing only readable data.  With the new layout, using
+MADV_GUARD_INSTALL instead of the older mechanism, it's often the case
+that thread stacks created with multiple calls to mmap() are exposed
+as a single mapping appearing in /proc/PID/smaps with read and write
+permissions.  Should that happen, GDB's code creates a single section
+covering all thread stacks and their guard pages.  (Even if each
+thread stack appears in its own mapping, the fact remains that there
+will be an inaccessible portion of the mapping.  When one or more
+thread stacks are coalesced into a single mapping, there will be
+several inaccessible "holes" representing the guard pages.)
+
+When gcore_copy_callback copies section contents, it reads memory in
+1MB (MAX_COPY_BYTES) chunks.  If any page in the chunk is a guard page,
+the call to target_read_memory() fails.  The old code responded by
+breaking out of the copy loop, abandoning the entire section.  This
+prevents correct copying of thread stack data, resulting in core files
+with zero-filled thread stacks, resulting in nearly empty backtraces.
+
+Fix this by falling back to page-by-page reading when a 1MB chunk read
+fails.  Individual pages that cannot be read are filled with zeros,
+allowing the remaining readable memory to be captured.
+
+I also considered a simpler change using the value of
+FALLBACK_PAGE_SIZE (4096) as the read size instead of MAX_COPY_BYTES
+(1MB).  This would avoid the fallback logic but would cause up to 256x
+more syscalls.  The proposed approach also allows meaningful warnings:
+we warn only if an entire region is unreadable (indicating a real
+problem), whereas per-page reads would make it harder to distinguish
+guard page failures from actual errors.  Since guard pages are at
+offset 0 for downward-growing stacks, a large target_read_memory()
+fails early at the first unreadable byte anyway.
+
+With this fix, I see 16 failures resolved in the following test cases:
+
+    gdb.ada/task_switch_in_core.exp
+    gdb.arch/i386-tls-regs.exp
+    gdb.threads/threadcrash.exp
+    gdb.threads/tls-core.exp
+
+Looking at just one of these, from gdb.log without the fix, I see:
+
+  thread apply 5 backtrace
+
+  Thread 5 (LWP 3414829):
+  #0  0x00007ffff7d1d982 in __syscall_cancel_arch () from /lib64/libc.so.6
+  #1  0x0000000000000000 in ?? ()
+  (gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: thread apply 5 backtrace
+
+And this is what it looks like with the fix in place (some paths have
+been shortened):
+
+  thread apply 5 backtrace
+
+  Thread 5 (Thread 0x7fffeffff6c0 (LWP 1282651) "threadcrash"):
+  #0  0x00007ffff7d1d982 in __syscall_cancel_arch () from /lib64/libc.so.6
+  #1  0x00007ffff7d11c3c in __internal_syscall_cancel () from /lib64/libc.so.6
+  #2  0x00007ffff7d61b62 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6
+  #3  0x00007ffff7d6db37 in nanosleep () from /lib64/libc.so.6
+  #4  0x00007ffff7d8008e in sleep () from /lib64/libc.so.6
+  #5  0x00000000004006a8 in do_syscall_task (location=NORMAL) at threadcrash.c:158
+  #6  0x0000000000400885 in thread_function (arg=0x404340) at threadcrash.c:277
+  #7  0x00007ffff7d15464 in start_thread () from /lib64/libc.so.6
+  #8  0x00007ffff7d985ac in __clone3 () from /lib64/libc.so.6
+  (gdb) PASS: gdb.threads/threadcrash.exp: test_live_inferior: thread apply 5 backtrace
+
+Regression testing on Fedora 42 (glibc 2.41) shows no new failures.
+
+The v1 patch used SPARSE_BLOCK_SIZE as the fallback size.  While it
+was the correct size, it's used for an entirely different purpose
+elsewhere in this file.  This v2 commit introduces the constant
+FALLBACK_PAGE_SIZE instead.
+
+References:
+
+[1] Linux commit 662df3e5c376 ("mm: madvise: implement lightweight
+    guard page mechanism")
+    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=662df3e5c37666d6ed75c88098699e070a4b35b5
+[2] glibc commit a6fbe36b7f31 ("nptl: Add support for setup guard
+    pages with MADV_GUARD_INSTALL")
+    https://sourceware.org/git/?p=glibc.git;a=commit;h=a6fbe36b7f31292981422692236465ab56670ea9
+
+Claude Opus 4.5 and GLM 4.7 assisted with the development of this commit.
+
+Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33855
+Approved-By: Tom de Vries <tdevries@suse.de>
+
+diff --git a/gdb/gcore.c b/gdb/gcore.c
+--- a/gdb/gcore.c
++++ b/gdb/gcore.c
+@@ -744,6 +744,12 @@ sparse_bfd_set_section_contents (bfd *obfd, asection *osec,
+   return true;
+ }
+ 
++/* Fallback page size to use when target_read_memory fails when attempting
++   to read MAX_COPY_BYTES in gcore_copy_callback.  4KB is the correct size
++   to use for x86 and most other architectures.  Some may have larger pages,
++   but this size will still work at the cost of more syscalls.  */
++#define FALLBACK_PAGE_SIZE 0x1000
++
+ static void
+ gcore_copy_callback (bfd *obfd, asection *osec)
+ {
+@@ -766,15 +772,45 @@ gcore_copy_callback (bfd *obfd, asection *osec)
+       if (size > total_size)
+ 	size = total_size;
+ 
+-      if (target_read_memory (bfd_section_vma (osec) + offset,
+-			      memhunk.data (), size) != 0)
++      CORE_ADDR vma = bfd_section_vma (osec) + offset;
++
++      if (target_read_memory (vma, memhunk.data (), size) != 0)
+ 	{
+-	  warning (_("Memory read failed for corefile "
+-		     "section, %s bytes at %s."),
+-		   plongest (size),
+-		   paddress (current_inferior ()->arch (),
+-			     bfd_section_vma (osec)));
+-	  break;
++	  /* Large read failed.  This can happen when the memory region
++	     contains unreadable pages (such as guard pages embedded within
++	     a larger mapping).  Fall back to reading page by page, filling
++	     unreadable pages with zeros.  */
++	  gdb_byte *p = memhunk.data ();
++	  bfd_size_type remaining = size;
++	  CORE_ADDR addr = vma;
++	  bool at_least_one_page_read = false;
++
++	  while (remaining > 0)
++	    {
++	      bfd_size_type chunk_size
++		= std::min (remaining, (bfd_size_type) FALLBACK_PAGE_SIZE);
++
++	      if (target_read_memory (addr, p, chunk_size) != 0)
++		{
++		  /* Failed to read this page.  Fill with zeros.  This
++		     handles guard pages and other unreadable regions
++		     that may exist within a larger readable mapping.  */
++		  memset (p, 0, chunk_size);
++		}
++	      else
++		at_least_one_page_read = true;
++
++	      p += chunk_size;
++	      addr += chunk_size;
++	      remaining -= chunk_size;
++	    }
++	  /* Warn only if the entire region was unreadable - this
++	     indicates a real problem, not just embedded guard pages. */
++	  if (!at_least_one_page_read)
++	    warning (_("Memory read failed for corefile "
++		       "section, %s bytes at %s."),
++		     plongest (size),
++		     paddress (current_inferior ()->arch (), vma));
+ 	}
+ 
+       if (!sparse_bfd_set_section_contents (obfd, osec, memhunk.data (),

diff --git a/gdb.spec b/gdb.spec
index 7f03dcd..447dd37 100644
--- a/gdb.spec
+++ b/gdb.spec
@@ -932,6 +932,13 @@ fi
 # endif scl
 
 %changelog
+* Wed Feb 25 2026 Kevin Buettner <kevinb@redhat.com>
+- Backport upstream commit c1da013915e from Kevin Buettner to fix
+  gcore failures caused by glibc 2.42 guard page changes (RHBZ 2413405).
+- Backport upstream commit d2cc16cd7fc from Jan Vrany to fix
+  FAILs in gdb.base/fileio.exp caused by macro expansion of
+  path components in OUTDIR.
+
 * Mon Feb 16 2026 Guinevere Larsen <guinevere@redhat.com>
 - Backport upstream commit f08ffbbf269 to fix RHBZ 2435950
   This reverts a new feature that was never properly approved

^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2026-06-28  0:02 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-06-28  0:02 [rpms/gdb] gdb-17.2-rebase-f44: Backport commits to fix gcore failures and fileio.exp failures Kevin Buettner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox