pool/gdb
SHA256
12
0
Fork 2
Code Issues Pull Requests Activity

- Maintenance script qa.sh:

Browse Source 
* Add gdb.base/errno.exp FAILs for PR29244 (SLE-12).
  * Add PR31308 kfail.
- Maintenance script import-patches.sh:
  * Handle filename clash with existing file.
- Patches added:  
  * gdb-record-fix-out-of-bounds-write-in-aarch64_record.patch
  * gdb-block-sigterm-during-fetch_inferior_event.patch
  * gdb-testsuite-fix-another-timeout-in-gdb.base-bg-exe.1.patch
  * gdb-testsuite-fix-regexp-in-gdb.multi-pending-bp-del.patch
  * gdb-testsuite-fix-timeout-in-gdb.threads-main-thread.patch
  * gdb-testsuite-fix-gdb.threads-clone-attach-detach.ex.patch

OBS-URL: https://build.opensuse.org/package/show/devel:gcc/gdb?expand=0&rev=456
This commit is contained in:
Tom de Vries
2025-04-17 11:02:26 +00:00
committed by Git OBS Bridge
parent 7835e31530
commit 93394c973e
10 changed files with 590 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

92
gdb-block-sigterm-during-fetch_inferior_event.patch Normal file
View File

@@ -0,0 +1,92 @@
From 32a7b58de39da07e3449d90c31edb104e14480f1 Mon Sep 17 00:00:00 2001
From: Andrew Burgess <aburgess@redhat.com>
Date: Thu, 27 Feb 2025 11:31:02 +0000
Subject: [PATCH 2/5] gdb: block SIGTERM during fetch_inferior_event
I'm posting this as RFC. I started looking at this when I got a CI
failure email from Linaro about a regression on
gdb.base/gdb-sigerm.exp on ARM. Turns out is wasn't my fault, it's
just the precise failure point moves about, so it can look like a
regression.
After looking at it for a bit I realised this was PR gdb/31061, and
there have already been attempts to fix this over the last few years.
What I have here is different than any of the previous approaches
posted, but I'm still not entirely sure this is the right solution,
but I thought I'd share it. Might be nice to see if we can get this
fixed.
The patch might still need some cleanup, but it should be good enough
to discuss this approach.
Thanks,
Andrew
---
gdb/infrun.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 8a10119487c..cdce1c0b6c2 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -78,6 +78,7 @@
#include "extension.h"
#include "disasm.h"
#include "interps.h"
+#include "gdbsupport/scoped_ignore_signal.h"
/* Prototypes for local functions */
@@ -4574,6 +4575,31 @@ infrun_quit_handler ()
}
}
+/* Block SIGTERM and then clear sync_quit_force_run. When we go out of
+ scope, restore the previous sync_quit_force_run value, and then unblock
+ signals.
+
+ This should maybe live in a support file somewhere, but it needs to see
+ sync_quit_force_run, so likely needs to live in the gdb/ directory. */
+
+struct scoped_ignore_sigterm
+{
+ scoped_ignore_sigterm ()
+ : m_old_val (sync_quit_force_run)
+ {
+ sync_quit_force_run = false;
+ }
+
+ ~scoped_ignore_sigterm ()
+ {
+ sync_quit_force_run = m_old_val;
+ }
+
+private:
+ scoped_ignore_signal<SIGTERM, false> m_ignore_signal;
+ bool m_old_val;
+};
+
/* Asynchronous version of wait_for_inferior. It is called by the
event loop whenever a change of state is detected on the file
descriptor corresponding to the target. It can be called more than
@@ -4609,6 +4635,16 @@ fetch_inferior_event ()
scoped_restore restore_quit_handler
= make_scoped_restore (&quit_handler, infrun_quit_handler);
+ /* Similar to how the above custom quit handler ignores the quit flag
+ (thus not interrupting GDB on receipt of Ctrl-C), this arranges to
+ block SIGTERM while we are handling the inferior event. Any SIGTERM
+ will be deferred until this function is done. Usually SIGTERM is
+ converted to an exception by the QUIT macro, but doing that while
+ processing an inferior event can leave the inferior in a weird state,
+ e.g. some breakpoints not removed. Deferring SIGTERM handling until
+ after this function means the event should have been fully handled. */
+ scoped_ignore_sigterm ignore_sigterm;
+
/* Make sure a SIGINT does not interrupt an extension language while
we're handling an event. That could interrupt a Python unwinder
or a Python observer or some such. A Ctrl-C should either be
--
2.43.0

88
gdb-record-fix-out-of-bounds-write-in-aarch64_record.patch Normal file
View File

@@ -0,0 +1,88 @@
From 2960ff203989194d0be7155f3af5194da0b2ca17 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Thu, 13 Mar 2025 07:49:33 +0100
Subject: [PATCH 1/5] [gdb/record] Fix out-of-bounds write in
aarch64_record_asimd_load_store
After compiling gdb with -fstack-protector-all, and running test-case
gdb.reverse/getrandom.exp on aarch64-linux, we run into
"Stack smashing detected" in function aarch64_record_asimd_load_store.
This is reported in PR record/32784.
This happens due to an out-of-bounds write to local array record_buf_mem:
...
uint64_t record_buf_mem[24];
...
when recording insn:
...
B+>0xfffff7ff4d10 st1 {v0.16b-v3.16b}, [x0]
...
We can fix this by increasing the array size to 128, but rather than again
hardcoding a size, reimplement record_buf_mem as std::vector.
Tested on aarch64-linux.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32784
---
gdb/aarch64-tdep.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c
index bc8746e27f0..565b265ec6c 100644
--- a/gdb/aarch64-tdep.c
+++ b/gdb/aarch64-tdep.c
@@ -5200,9 +5200,9 @@ aarch64_record_asimd_load_store (aarch64_insn_decode_record *aarch64_insn_r)
CORE_ADDR address;
uint64_t addr_offset = 0;
uint32_t record_buf[24];
- uint64_t record_buf_mem[24];
+ std::vector<uint64_t> record_buf_mem;
uint32_t reg_rn, reg_rt;
- uint32_t reg_index = 0, mem_index = 0;
+ uint32_t reg_index = 0;
uint8_t opcode_bits, size_bits;
reg_rt = bits (aarch64_insn_r->aarch64_insn, 0, 4);
@@ -5265,8 +5265,8 @@ aarch64_record_asimd_load_store (aarch64_insn_decode_record *aarch64_insn_r)
record_buf[reg_index++] = reg_rt + AARCH64_V0_REGNUM;
else
{
- record_buf_mem[mem_index++] = esize / 8;
- record_buf_mem[mem_index++] = address + addr_offset;
+ record_buf_mem.push_back (esize / 8);
+ record_buf_mem.push_back (address + addr_offset);
}
addr_offset = addr_offset + (esize / 8);
reg_rt = (reg_rt + 1) % 32;
@@ -5337,8 +5337,8 @@ aarch64_record_asimd_load_store (aarch64_insn_decode_record *aarch64_insn_r)
record_buf[reg_index++] = reg_tt + AARCH64_V0_REGNUM;
else
{
- record_buf_mem[mem_index++] = esize / 8;
- record_buf_mem[mem_index++] = address + addr_offset;
+ record_buf_mem.push_back (esize / 8);
+ record_buf_mem.push_back (address + addr_offset);
}
addr_offset = addr_offset + (esize / 8);
reg_tt = (reg_tt + 1) % 32;
@@ -5350,9 +5350,9 @@ aarch64_record_asimd_load_store (aarch64_insn_decode_record *aarch64_insn_r)
record_buf[reg_index++] = reg_rn;
aarch64_insn_r->reg_rec_count = reg_index;
- aarch64_insn_r->mem_rec_count = mem_index / 2;
+ aarch64_insn_r->mem_rec_count = record_buf_mem.size () / 2;
MEM_ALLOC (aarch64_insn_r->aarch64_mems, aarch64_insn_r->mem_rec_count,
- record_buf_mem);
+ record_buf_mem.data ());
REG_ALLOC (aarch64_insn_r->aarch64_regs, aarch64_insn_r->reg_rec_count,
record_buf);
return AARCH64_RECORD_SUCCESS;
base-commit: da7e8a0d1123742e9e116a32afbe5d95b3b9256d
--
2.43.0

78
gdb-testsuite-fix-another-timeout-in-gdb.base-bg-exe.1.patch Normal file
View File

@@ -0,0 +1,78 @@
From a4f602690bdc46428b7e9003612b524dec3ab014 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Mon, 14 Apr 2025 13:05:35 +0200
Subject: [PATCH 3/5] [gdb/testsuite] Fix another timeout in
gdb.base/bg-execution-repeat.exp
With test-case gdb.base/bg-execution-repeat.exp, occasionally I run into a
timeout:
...
(gdb) c 1&
Will stop next time breakpoint 1 is reached. Continuing.
(gdb) PASS: $exp: c 1&: c 1&
Breakpoint 2, foo () at bg-execution-repeat.c:23
23 return 0; /* set break here */
PASS: $exp: c 1&: breakpoint hit 1
Will stop next time breakpoint 2 is reached. Continuing.
(gdb) PASS: $exp: c 1&: repeat bg command
print 1
$1 = 1
(gdb) PASS: $exp: c 1&: input still accepted
interrupt
(gdb) PASS: $exp: c 1&: interrupt
Program received signal SIGINT, Interrupt.
foo () at bg-execution-repeat.c:24
24 }
PASS: $exp: c 1&: interrupt received
set var do_wait=0
(gdb) PASS: $exp: c 1&: set var do_wait=0
continue&
Continuing.
(gdb) PASS: $exp: c 1&: continue&
FAIL: $exp: c 1&: breakpoint hit 2 (timeout)
...
I can reproduce it reliably by adding a "sleep (1)" before the "do_wait = 1"
in the .c file.
The timeout happens as follows:
- with the inferior stopped at main, gdb continues (command c 1&)
- the inferior hits the breakpoint at foo
- gdb continues (using the repeat command functionality)
- the inferior is interrupted
- inferior variable do_wait gets set to 0. The assumption here is that the
inferior has progressed enough that do_wait is set to 1 at that point, but
that happens not to be the case. Consequently, this has no effect.
- gdb continues
- the inferior sets do_wait to 1
- the inferior enters the wait function, and wait for do_wait to become 0,
which never happens.
Fix this by moving the "do_wait = 1" to before the first call to foo.
Tested on x86_64-linux.
---
gdb/testsuite/gdb.base/bg-execution-repeat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdb/testsuite/gdb.base/bg-execution-repeat.c b/gdb/testsuite/gdb.base/bg-execution-repeat.c
index d5b48ee4f94..3e9132b3ee5 100644
--- a/gdb/testsuite/gdb.base/bg-execution-repeat.c
+++ b/gdb/testsuite/gdb.base/bg-execution-repeat.c
@@ -37,9 +37,9 @@ main (void)
{
alarm (60);
+ do_wait = 1;
foo ();
- do_wait = 1;
wait ();
/* do_wait set to 0 externally. */
--
2.43.0

52
gdb-testsuite-fix-gdb.threads-clone-attach-detach.ex.patch Normal file
View File

@@ -0,0 +1,52 @@
From 06ca9655c99ce4881f922a5cbac092f0ed0a958b Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Mon, 14 Apr 2025 18:25:57 +0200
Subject: [PATCH] [gdb/testsuite] Fix gdb.threads/clone-attach-detach.exp
With test-case gdb.threads/clone-attach-detach.exp I usually get:
...
(gdb) attach <pid> &^M
Attaching to program: clone-attach-detach, process <pid>^M
[New LWP <lwp>]^M
(gdb) PASS: $exp: bg attach <n>: attach
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
...
but sometimes I run into:
...
(gdb) attach <pid> &^M
Attaching to program: clone-attach-detach, process <pid>^M
[New LWP <lwp>]^M
(gdb) [Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
FAIL: $exp: bg attach <n>: attach (timeout)
...
I managed to reproduce this using make target check-readmore and
READMORE_SLEEP=100.
Fix this using -no-prompt-anchor.
Tested on x86_64-linux.
---
gdb/testsuite/gdb.threads/clone-attach-detach.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdb/testsuite/gdb.threads/clone-attach-detach.exp b/gdb/testsuite/gdb.threads/clone-attach-detach.exp
index de1f6a445a4..21e9649bab1 100644
--- a/gdb/testsuite/gdb.threads/clone-attach-detach.exp
+++ b/gdb/testsuite/gdb.threads/clone-attach-detach.exp
@@ -74,7 +74,7 @@ set attempts 3
for {set attempt 1} {$attempt <= $attempts} {incr attempt} {
with_test_prefix "bg attach $attempt" {
- gdb_test "attach $testpid &" \
+ gdb_test -no-prompt-anchor "attach $testpid &" \
"Attaching to program.*process $testpid.*" \
"attach"
base-commit: e026bf5856f23e9f2bb65b1b01c52d77f106ade8
--
2.43.0

76
gdb-testsuite-fix-regexp-in-gdb.multi-pending-bp-del.patch Normal file
View File

@@ -0,0 +1,76 @@
From 0d159d85cd29ea1b4c3abfde2de2c92ad91ddd53 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Mon, 14 Apr 2025 15:24:55 +0200
Subject: [PATCH 4/5] [gdb/testsuite] Fix regexp in
gdb.multi/pending-bp-del-inferior.exp
With test-case gdb.multi/pending-bp-del-inferior.exp, occasionally I run into:
...
(gdb) info breakpoints^M
Num Type Disp Enb Address What^M
3 dprintf keep y <MULTIPLE> ^M
printf "in foo"^M
3.1 y 0x004004dc in foo at $c:21 inf 2^M
3.2 y 0x004004dc in foo at $c:21 inf 1^M
(gdb) FAIL: $exp: bp_pending=false: info breakpoints before inferior removal
...
The FAIL happens because the test-case expects:
- breakpoint location 3.1 to be in inferior 1, and
- breakpoint location 3.2 to be in inferior 2
but it's the other way around.
I managed to reproduce this with a trigger patch in
compare_symbols from gdb/linespec.c:
...
uia = (uintptr_t) a.symbol->symtab ()->compunit ()->objfile ()->pspace ();
uib = (uintptr_t) b.symbol->symtab ()->compunit ()->objfile ()->pspace ();
- if (uia < uib)
- return true;
if (uia > uib)
+ return true;
+ if (uia < uib)
return false;
...
Fix this by allowing the alternative order.
Tested on x86_64-linux.
PR testsuite/32202
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32202
---
.../gdb.multi/pending-bp-del-inferior.exp | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/gdb/testsuite/gdb.multi/pending-bp-del-inferior.exp b/gdb/testsuite/gdb.multi/pending-bp-del-inferior.exp
index 12c0a84bb02..2226acb5d78 100644
--- a/gdb/testsuite/gdb.multi/pending-bp-del-inferior.exp
+++ b/gdb/testsuite/gdb.multi/pending-bp-del-inferior.exp
@@ -183,12 +183,16 @@ proc do_dprintf_test { bp_pending } {
"\\s+printf \"in $bp_func\""]
set bp_pattern_after $bp_pattern_before
} else {
- set bp_pattern_before \
- [multi_line \
- "$bp_number\\s+dprintf\\s+keep\\s+y\\s+<MULTIPLE>\\s*" \
- "\\s+printf \"in $bp_func\"" \
- "$bp_number\\.1\\s+y\\s+$::hex in $bp_func at \[^\r\n\]+ inf 1" \
- "$bp_number\\.2\\s+y\\s+$::hex in $bp_func at \[^\r\n\]+ inf 2"]
+ set res {}
+ foreach inf_a { 1 2 } inf_b { 2 1 } {
+ lappend res \
+ [multi_line \
+ "$bp_number\\s+dprintf\\s+keep\\s+y\\s+<MULTIPLE>\\s*" \
+ "\\s+printf \"in $bp_func\"" \
+ "$bp_number\\.1\\s+y\\s+$::hex in $bp_func at \[^\r\n\]+ inf $inf_a" \
+ "$bp_number\\.2\\s+y\\s+$::hex in $bp_func at \[^\r\n\]+ inf $inf_b"]
+ }
+ set bp_pattern_before "([join $res "|"])"
set bp_pattern_after \
[multi_line \
--
2.43.0

156
gdb-testsuite-fix-timeout-in-gdb.threads-main-thread.patch Normal file
View File

@@ -0,0 +1,156 @@
From e026bf5856f23e9f2bb65b1b01c52d77f106ade8 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Tue, 18 Mar 2025 14:17:50 +0100
Subject: [PATCH 5/5] [gdb/testsuite] Fix timeout in
gdb.threads/main-thread-exit-during-detach.exp
With a gdb 15.2 based package and test-case
gdb.threads/main-thread-exit-during-detach.exp, I ran into:
...
(gdb) attach 23068
Attaching to program: main-thread-exit-during-detach, process 23068
[New LWP 23080]
...
0x0000ffffb79aa178 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6
(gdb) PASS: $exp: spawn_inferior=true: attach to the inferior
p 1 + 2
$1 = 3
(gdb)
Thread 2 "main-thread-exi" stopped.
0x0000ffffb79aa178 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6
FAIL: $exp: spawn_inferior=true: p 1 + 2 (timeout)
...
I managed to reproduce this using two timing hacks.
First, we hack display_gdb_prompt to sleep half a second at the end:
...
printf_unfiltered ("%s", actual_gdb_prompt.c_str ());
gdb_flush (gdb_stdout);
}
+ usleep (500 * 1000);
}
...
to make sure expect has time to:
- parse the output of the attach command up until the prompt,
- issue "PASS: $exp: spawn_inferior=true: attach to the inferior", and
- issue "p 1 + 2"
before gdb issues the "Thread ... stopped." message.
Then we hack proc run_test to wait a while between issuing the print command
and parsing the output:
...
- gdb_test "p 1 + 2" " = 3"
+ set cmd "p 1 + 2"
+ send_gdb "$cmd\n"
+ sleep 1
+ gdb_test "" " = 3" $cmd
...
to make sure that gdb has the time to issue the "Thread ... stopped." message
before the output is parsed.
We could fix this by just using -no-prompt-anchor on the print command, but
there's another issue here.
As explained in the test-case, the setup phase is complete if thread 2 is
stopped:
...
# Setup the inferior. When complete the main thread (#1) will
# still be running (due to non-stop mode), while the worker thread
# (#2) will be stopped.
...
The stated goal of the print statement is:
...
# Attaching to a multi-threaded application in non-stop mode
# can result in thread stops being reported after the prompt
# is displayed.
#
# Send a simple command now just to resync the command prompt.
gdb_test "p 1 + 2" " = 3"
...
so the implicit assumption here seems to be that after this gdb_test, thread 2
is in fact stopped.
However, considering that the reported thread stop is the result of a waitpid
call, which is the result of a SIGSTOP arriving at the thread, I don't think
we can make assumptions about when the thread stop will be reported.
We could fix this by trying to detect the "Thread ... stopped." message, but
doing so will make the test-case much more complex, because it may occur
before and after the attach.
So instead, after the attach, loop doing "info thread 2" until the thread is
no longer reported as running:
...
(gdb) attach 8598^M
Attaching to program: main-thread-exit-during-detach, process 8598^M
[New LWP 8608]^M
...
0x00007f23044f1545 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
(gdb) PASS: $exp: spawn_inferior=true: attach to the inferior
info thread 2^M
Id Target Id Frame ^M
2 Thread 0x7f23043ff6c0 (LWP 8608) "main-thread-exi" (running)^M
(gdb) ^M
Thread 2 "main-thread-exi" stopped.^M
0x00007f23044f1545 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
info thread 2^M
Id Target Id Frame ^M
2 Thread 0x7f23043ff6c0 (LWP 8608) "main-thread-exi" 0x00007f23044f1545 \
in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
(gdb) PASS: $exp: spawn_inferior=true: Thread 2 stopped
...
Tested on x86_64-linux.
PR testsuite/32798
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32798
---
.../main-thread-exit-during-detach.exp | 29 +++++++++++++++++--
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/gdb/testsuite/gdb.threads/main-thread-exit-during-detach.exp b/gdb/testsuite/gdb.threads/main-thread-exit-during-detach.exp
index 2a9320a6914..7d6b3845f1e 100644
--- a/gdb/testsuite/gdb.threads/main-thread-exit-during-detach.exp
+++ b/gdb/testsuite/gdb.threads/main-thread-exit-during-detach.exp
@@ -76,10 +76,33 @@ proc run_test { spawn_inferior } {
# Attaching to a multi-threaded application in non-stop mode
# can result in thread stops being reported after the prompt
- # is displayed.
+ # is displayed, so the thread may still be reported as running.
#
- # Send a simple command now just to resync the command prompt.
- gdb_test "p 1 + 2" " = 3"
+ # Iterate until the thread is no longer reported as running.
+ set stopped 0
+ set re_running [string_to_regexp "(running)"]
+ for { set i 0 } { $i < 10 } { incr i } {
+ with_test_prefix $i {
+ gdb_test_multiple "info thread 2" "" -no-prompt-anchor {
+ -re -wrap $re_running.* {
+ }
+ -re -wrap "" {
+ set stopped 1
+ }
+ }
+ }
+ if { $stopped } {
+ break
+ }
+
+ # Back off to let gdb and inferior make progress.
+ sleep 1
+ }
+
+ gdb_assert { $stopped } "Thread 2 stopped"
+ if { ! $stopped } {
+ return -1
+ }
# Set thread 1 (the current thread) running again.
gdb_test "continue&"
--
2.43.0

16
gdb.changes
View File

@@ -1,3 +1,19 @@
-------------------------------------------------------------------
Mon Apr 14 14:43:51 UTC 2025 - Tom de Vries <tdevries@suse.com>
- Maintenance script qa.sh:
* Add gdb.base/errno.exp FAILs for PR29244 (SLE-12).
* Add PR31308 kfail.
- Maintenance script import-patches.sh:
* Handle filename clash with existing file.
- Patches added:
* gdb-record-fix-out-of-bounds-write-in-aarch64_record.patch
* gdb-block-sigterm-during-fetch_inferior_event.patch
* gdb-testsuite-fix-another-timeout-in-gdb.base-bg-exe.1.patch
* gdb-testsuite-fix-regexp-in-gdb.multi-pending-bp-del.patch
* gdb-testsuite-fix-timeout-in-gdb.threads-main-thread.patch
* gdb-testsuite-fix-gdb.threads-clone-attach-detach.ex.patch
-------------------------------------------------------------------
Sat Apr 12 09:52:17 UTC 2025 - Tom de Vries <tdevries@suse.com>

20
gdb.spec
View File

@@ -214,6 +214,10 @@ Patch1508: gdb-testsuite-fix-gdb_py_module_available-for-python.patch
# https://sourceware.org/bugzilla/show_bug.cgi?id=32850
Patch1509: gdb-testsuite-work-around-pr32850.patch
# Backports from master, available in GDB 16.3.
Patch2000: gdb-record-fix-out-of-bounds-write-in-aarch64_record.patch
# Backports from master, available in GDB 17.
Patch2100: gdb-testsuite-record-less-in-gdb.reverse-time-revers.patch
@@ -244,6 +248,7 @@ Patch2126: gdb-testsuite-fix-gdb.threads-access-mem-running-thr.patch
Patch2127: gdb-guile-use-scm_debug_typing_strictness-0.patch
Patch2128: gdb-testsuite-fix-gdb.dwarf2-implptr.exp-regression.patch
Patch2129: gdb-symtab-fix-gdb.base-fission-macro.exp-with-unix-.patch
Patch2130: gdb-testsuite-fix-gdb.threads-clone-attach-detach.ex.patch
# Backport from gdb-patches
@@ -265,6 +270,14 @@ Patch3008: gdb-testsuite-add-gdb.arch-s390-disassemble.exp.patch
Patch3009: gdb-tui-enable-work-around-libncurses-segfault.patch
# https://sourceware.org/pipermail/gdb-patches/2025-April/217098.html
Patch3010: gdb-testsuite-fix-another-timeout-in-gdb.base-bg-exe.patch
# https://sourceware.org/pipermail/gdb-patches/2025-February/215898.html
Patch3011: gdb-block-sigterm-during-fetch_inferior_event.patch
# https://sourceware.org/pipermail/gdb-patches/2025-April/217188.html
Patch3012: gdb-testsuite-fix-another-timeout-in-gdb.base-bg-exe.1.patch
# https://sourceware.org/pipermail/gdb-patches/2025-April/217193.html
Patch3013: gdb-testsuite-fix-regexp-in-gdb.multi-pending-bp-del.patch
# https://sourceware.org/pipermail/gdb-patches/2025-March/216441.html
Patch3014: gdb-testsuite-fix-timeout-in-gdb.threads-main-thread.patch
# Debug patches.
@@ -611,6 +624,8 @@ find -name "*.info*"|xargs rm -f
%patch -P 1508 -p1
%patch -P 1509 -p1
%patch -P 2000 -p1
%patch -P 2100 -p1
%patch -P 2101 -p1
%patch -P 2102 -p1
@@ -639,6 +654,7 @@ find -name "*.info*"|xargs rm -f
%patch -P 2127 -p1
%patch -P 2128 -p1
%patch -P 2129 -p1
%patch -P 2130 -p1
%patch -P 3000 -p1
%patch -P 3001 -p1
@@ -649,6 +665,10 @@ find -name "*.info*"|xargs rm -f
%patch -P 3008 -p1
%patch -P 3009 -p1
%patch -P 3010 -p1
%patch -P 3011 -p1
%patch -P 3012 -p1
%patch -P 3013 -p1
%patch -P 3014 -p1
#unpack libipt
%if 0%{have_libipt}

5
import-patches.sh
View File

@@ -62,6 +62,11 @@ for f in $files; do
# Fix patch.patch.
f=$(echo "$f" \
| sed 's/\.patch\.patch/.patch/')
if [ -f "$f" ]; then
f=$(echo "$f" \
| sed 's/\.patch$/.1.patch/')
fi
# Copy.
cp "$dir"/"$orig_f" tmp.patches/"$f"

7
qa.sh
View File

@@ -367,6 +367,9 @@ kfail=(
# https://sourceware.org/bugzilla/show_bug.cgi?id=32688
"FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end"
# https://sourceware.org/bugzilla/show_bug.cgi?id=31308
"FAIL: gdb.arch/amd64-init-x87-values.exp: check_setting_mxcsr_before_enable: check new value of MXCSR is still in place"
) # kfail
kfail_sle12=(
@@ -437,6 +440,10 @@ kfail_sle12=(
"FAIL: gdb.dwarf2/frame-inlined-in-outer-frame.exp: step into bar"
"FAIL: gdb.dwarf2/frame-inlined-in-outer-frame.exp: step into foo"
"FAIL: gdb.base/list-dot-nodebug.exp: debug=none: runto: run to bar"
"FAIL: gdb.base/errno.exp: pthreads-static-macros: runto: run to main"
"FAIL: gdb.base/errno.exp: pthreads-static: runto: run to main"
"FAIL: gdb.base/errno.exp: static-macros: runto: run to main"
"FAIL: gdb.base/errno.exp: static: runto: run to main"
# Fails on both i586 and s390x/-m31 for SLE-12-SP3, but does not reproduce
# on s390x/-m31 for SLE-12-SP5 with trunk.