public inbox for git-commits@fedoraproject.org
help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: git-commits@fedoraproject.org
Subject: [rpms/gdb] gdb-17.2-rebase-f44: Backport commits to fix gcore failures and fileio.exp failures
Date: Sun, 28 Jun 2026 00:02:21 GMT [thread overview]
Message-ID: <178260494124.1.10840984726020279836.rpms-gdb-54912b4e61eb@fedoraproject.org> (raw)
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
reply other threads:[~2026-06-28 0:02 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=178260494124.1.10840984726020279836.rpms-gdb-54912b4e61eb@fedoraproject.org \
--to=kevinb@redhat.com \
--cc=git-commits@fedoraproject.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