pool/gdb
SHA256
4
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

- Patches dropped:

Browse Source 
* fix-gdb.threads-threads-after-exec.exp-race.patch
  * add-maint-info-linux-lwps-command.patch
- Patches added:
  * gdb-python-fix-gdb.python-py-disasm.exp-on-arm-linux.patch
  * gdb-testsuite-fix-gdb.fortran-array-bounds.exp-on-ar.patch
  * gdb-python-make-gdb.unwindinfo.add_saved_register-mo-fixup.patch
  * exp-redo-cast-handling-for-indirection.patch
  * gdb-tdep-fix-gdb.base-watchpoint-running-on-arm-ppc6.patch

OBS-URL: https://build.opensuse.org/package/show/devel:gcc/gdb?expand=0&rev=389
This commit is contained in:
Tom de Vries 2024-06-13 09:00:01 +00:00 committed by Git OBS Bridge
parent 17c1e52bcb
commit 9f8d02b6db
9 changed files with 478 additions and 209 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
add-maint-info-linux-lwps-command.patch
View File

@ -1,108 +0,0 @@
From ab0396671d0d5f05573837171e0f2180ab194411 Mon Sep 17 00:00:00 2001
From: Andrew Burgess <aburgess@redhat.com>
Date: Tue, 4 Apr 2023 14:50:35 +0100
Subject: [PATCH 6/7] Add "maint info linux-lwps" command
This adds a maintenance command that lets you list all the LWPs under
control of the linux-nat target.
For example:
(gdb) maint info linux-lwps
LWP Ptid Thread ID
560948.561047.0 None
560948.560948.0 1.1
This shows that "560948.561047.0" LWP doesn't map to any thread_info
object, which is bogus. We'll be using this in a testcase in a
following patch.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Ic4e9e123385976e5cd054391990124b7a20fb3f5
---
gdb/doc/gdb.texinfo | 4 ++++
gdb/linux-nat.c | 46 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index c277c16297c..ad9d89796bc 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -41208,6 +41208,10 @@ module (@pxref{Disassembly In Python}), and will only be present after
that module has been imported. To force the module to be imported do
the following:
+@kindex maint info linux-lwps
+@item maint info linux-lwps
+Print information about LWPs under control of the Linux native target.
+
@smallexample
(@value{GDBP}) python import gdb.disassembler
@end smallexample
diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index 2f89d283acc..a3ff6036e98 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -4522,6 +4522,49 @@ current_lwp_ptid (void)
return inferior_ptid;
}
+/* Implement 'maintenance info linux-lwps'. Displays some basic
+ information about all the current lwp_info objects. */
+
+static void
+maintenance_info_lwps (const char *arg, int from_tty)
+{
+ if (all_lwps ().size () == 0)
+ {
+ gdb_printf ("No Linux LWPs\n");
+ return;
+ }
+
+ /* Start the width at 8 to match the column heading below, then
+ figure out the widest ptid string. We'll use this to build our
+ output table below. */
+ size_t ptid_width = 8;
+ for (lwp_info *lp : all_lwps ())
+ ptid_width = std::max (ptid_width, lp->ptid.to_string ().size ());
+
+ /* Setup the table headers. */
+ struct ui_out *uiout = current_uiout;
+ ui_out_emit_table table_emitter (uiout, 2, -1, "linux-lwps");
+ uiout->table_header (ptid_width, ui_left, "lwp-ptid", _("LWP Ptid"));
+ uiout->table_header (9, ui_left, "thread-info", _("Thread ID"));
+ uiout->table_body ();
+
+ /* Display one table row for each lwp_info. */
+ for (lwp_info *lp : all_lwps ())
+ {
+ ui_out_emit_tuple tuple_emitter (uiout, "lwp-entry");
+
+ thread_info *th = linux_target->find_thread (lp->ptid);
+
+ uiout->field_string ("lwp-ptid", lp->ptid.to_string ().c_str ());
+ if (th == nullptr)
+ uiout->field_string ("thread-info", "None");
+ else
+ uiout->field_string ("thread-info", print_full_thread_id (th));
+
+ uiout->message ("\n");
+ }
+}
+
void _initialize_linux_nat ();
void
_initialize_linux_nat ()
@@ -4559,6 +4602,9 @@ Enables printf debugging output."),
sigemptyset (&blocked_mask);
lwp_lwpid_htab_create ();
+
+ add_cmd ("linux-lwps", class_maintenance, maintenance_info_lwps,
+ _("List the Linux LWPS."), &maintenanceinfolist);
}
--
2.35.3

97
fix-gdb.threads-threads-after-exec.exp-race.patch
View File

@ -1,97 +0,0 @@
From 800e56a120419b457ebda18c5478ebfea99f9b3a Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Tue, 14 Nov 2023 11:47:15 +0000
Subject: [PATCH 7/7] Fix gdb.threads/threads-after-exec.exp race
Simon noticed that gdb.threads/threads-after-exec.exp was racy. You
can consistenly reproduce it (at git hash
319b460545dc79280e2904dcc280057cf71fb753), with:
$ taskset -c 0 make check TESTS="gdb.threads/threads-after-exec.exp"
gdb.log shows:
(...)
Thread 3 "threads-after-e" hit Catchpoint 2 (exec'd .../gdb.threads/threads-after-exec/threads-after-exec), 0x00007ffff7fe3290
in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) PASS: gdb.threads/threads-after-exec.exp: continue until exec
info threads
Id Target Id Frame
* 3 process 1443269 "threads-after-e" 0x00007ffff7fe3290 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) FAIL: gdb.threads/threads-after-exec.exp: info threads
(...)
maint info linux-lwps
LWP Ptid Thread ID
1443269.1443269.0 1.3
(gdb) FAIL: gdb.threads/threads-after-exec.exp: maint info linux-lwps
The FAILs happen because the .exp file expects that after the exec,
the only thread has GDB thread number 1, but it has instead 3.
This is yet another case of zombie leader detection making things a
bit fuzzy.
In the passing case, we have:
continue
Continuing.
[New Thread 0x7ffff7bff640 (LWP 603183)]
[Thread 0x7ffff7bff640 (LWP 603183) exited]
process 603180 is executing new program: .../gdb.threads/threads-after-exec/threads-after-exec
While in the failing case, we have (note remarks on the rhs):
continue
Continuing.
[New Thread 0x7ffff7bff640 (LWP 600205)]
[Thread 0x7ffff7f95740 (LWP 600202) exited] <<< gdb deletes leader thread, thread 1.
[New LWP 600202] <<< gdb adds it back -- this is now thread 3.
[Thread 0x7ffff7bff640 (LWP 600205) exited]
process 600202 is executing new program: .../threads-after-exec/threads-after-exec
The testcase only has two threads, yet GDB presented the exec for
thread 3. This is GDB deleting the leader (the backend detected it
was zombie, due to the exec), and then adding the leader back when it
saw the exec event.
I've recorded some thoughts about this in PR gdb/31069.
For now, this commit just makes the testcase cope with the non-one
thread number, as the number is not important for what this test is
exercising.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31069
Change-Id: Id80b5c73f09c9e0005efeb494cca5d066ac3bbae
---
gdb/testsuite/gdb.threads/threads-after-exec.exp | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/gdb/testsuite/gdb.threads/threads-after-exec.exp b/gdb/testsuite/gdb.threads/threads-after-exec.exp
index cd8adf900d9..8d5a518f7b6 100644
--- a/gdb/testsuite/gdb.threads/threads-after-exec.exp
+++ b/gdb/testsuite/gdb.threads/threads-after-exec.exp
@@ -32,14 +32,18 @@ proc do_test { } {
gdb_test "continue" "Catchpoint $::decimal .*" "continue until exec"
# Confirm we only have one thread in the thread list.
- gdb_test "info threads" "\\* 1\[ \t\]+\[^\r\n\]+.*"
+ gdb_test "p \$_inferior_thread_count" " = 1"
+
+ # Get the post-exec thread number. Due to PR gdb/31069 ("Zombie
+ # leader detection racy") this isn't always thread 1.1.
+ set cur_thr [get_integer_valueof "\$_thread" 0]
if {[istarget *-*-linux*] && [gdb_is_target_native]} {
# Confirm there's only one LWP in the list as well, and that
- # it is bound to thread 1.1.
+ # it is bound to the existing GDB thread.
set inf_pid [get_inferior_pid]
gdb_test_multiple "maint info linux-lwps" "" {
- -wrap -re "Thread ID *\r\n$inf_pid\.$inf_pid\.0\[ \t\]+1\.1 *" {
+ -wrap -re "Thread ID *\r\n$inf_pid\.$inf_pid\.0\[ \t\]+1\.$cur_thr *" {
pass $gdb_test_name
}
}
--
2.35.3

86
gdb-exp-redo-cast-handling-for-indirection.patch Normal file
View File

@ -0,0 +1,86 @@
From a6800d9c8145f25001dd39afc3571e3350573e81 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Mon, 6 May 2024 14:23:25 +0200
Subject: [PATCH] [gdb/exp] Redo cast handling for indirection
In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I
introduced the behaviour that even though we have:
...
(gdb) p *a_loc ()
'a_loc' has unknown return type; cast the call to its declared return type
...
we get:
...
(gdb) p (char)*a_loc ()
$1 = 97 'a'
...
In other words, the unknown return type of a_loc is inferred from the cast,
effectually evaluating:
...
(gdb) p (char)*(char *)a_loc ()
...
This is convient for the case that errno is defined as:
...
#define errno (*__errno_location ())
...
and the return type of __errno_location is unknown but the macro definition is
known, such that we can use:
...
(gdb) p (int)errno
...
instead of
...
(gdb) p *(int *)__errno_location ()
...
However, as Pedro has pointed out in post-commit review [1], this makes it
harder to reason about the semantics of an expression.
For instance, this:
...
(gdb) p (long long)*a_loc ()"
...
would be evaluated without debug info as:
...
(gdb) p (long long)*(long long *)a_loc ()"
...
but with debug info as:
...
(gdb) p (long long)*(char *)a_loc ()"
...
Fix this by instead simply erroring out for this case:
...
(gdb) p (char)*a_loc ()
'a_loc' has unknown return type; cast the call to its declared return type
...
Tested on x86_64-linux.
Approved-By: Pedro Alves <pedro@palves.net>
[1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html
---
gdb/testsuite/gdb.base/cast-indirection.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gdb/testsuite/gdb.base/cast-indirection.exp b/gdb/testsuite/gdb.base/cast-indirection.exp
index f1fe4302d27..7b9b5a5d677 100644
--- a/gdb/testsuite/gdb.base/cast-indirection.exp
+++ b/gdb/testsuite/gdb.base/cast-indirection.exp
@@ -13,7 +13,7 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
-# Check that "p (char)*a_loc ()" is handled as "p (char)*(char *)a_loc ()".
+# Check that "p (char)*a_loc ()" is handled correctly.
standard_testfile
base-commit: fc73000faa1798573090994167b7e2d451c211db
--
2.35.3

125
gdb-python-fix-gdb.python-py-disasm.exp-on-arm-linux.patch Normal file
View File

@ -0,0 +1,125 @@
From 4c7dab250c3581e691c2da87395e80244074d8bf Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Mon, 10 Jun 2024 17:53:30 +0200
Subject: [PATCH] [gdb/python] Fix gdb.python/py-disasm.exp on arm-linux
After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop:
...
nop {0}
...
we run into:
...
disassemble test^M
Dump of assembler code for function test:^M
0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M
0x004004dc <+4>: add r11, sp, #0^M
0x004004e0 <+8>: nop {0}^M
=> 0x004004e4 <+12>: Python Exception <class 'ValueError'>: Buffer \
returned from read_memory is sized 0 instead of the expected 4^M
^M
unknown disassembler error (error = -1)^M
(gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test
...
This is caused by this code in gdbpy_disassembler::read_memory_func:
...
gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj,
"read_memory",
"KL", len, offset));
...
where len has type "unsigned int", while "K" means "unsigned long long" [1].
Fix this by using "I" instead, meaning "unsigned int".
Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means
"long long".
Fix this by using type gdb_py_longest for offset, in combination with format
character "GDB_PY_LL_ARG". Likewise in disasmpy_info_read_memory.
Tested on arm-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31845
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845
[1] https://docs.python.org/3/c-api/arg.html
(cherry picked from commit 4cd214dce4579f86a85a96c882e0fc8c4d94601c)
---
gdb/python/py-disasm.c | 12 +++++++-----
gdb/testsuite/gdb.python/py-disasm.exp | 2 +-
gdb/testsuite/gdb.python/py-disasm.py | 2 +-
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/gdb/python/py-disasm.c b/gdb/python/py-disasm.c
index 6f0fed137e6..b2e95b3cba6 100644
--- a/gdb/python/py-disasm.c
+++ b/gdb/python/py-disasm.c
@@ -668,12 +668,13 @@ disasmpy_info_read_memory (PyObject *self, PyObject *args, PyObject *kw)
disasm_info_object *obj = (disasm_info_object *) self;
DISASMPY_DISASM_INFO_REQUIRE_VALID (obj);
- LONGEST length, offset = 0;
+ gdb_py_longest length, offset = 0;
gdb::unique_xmalloc_ptr<gdb_byte> buffer;
static const char *keywords[] = { "length", "offset", nullptr };
- if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "L|L", keywords,
- &length, &offset))
+ if (!gdb_PyArg_ParseTupleAndKeywords (args, kw,
+ GDB_PY_LL_ARG "|" GDB_PY_LL_ARG,
+ keywords, &length, &offset))
return nullptr;
/* The apparent address from which we are reading memory. Note that in
@@ -850,13 +851,14 @@ gdbpy_disassembler::read_memory_func (bfd_vma memaddr, gdb_byte *buff,
/* The DisassembleInfo.read_memory method expects an offset from the
address stored within the DisassembleInfo object; calculate that
offset here. */
- LONGEST offset = (LONGEST) memaddr - (LONGEST) obj->address;
+ gdb_py_longest offset
+ = (gdb_py_longest) memaddr - (gdb_py_longest) obj->address;
/* Now call the DisassembleInfo.read_memory method. This might have been
overridden by the user. */
gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj,
"read_memory",
- "KL", len, offset));
+ "I" GDB_PY_LL_ARG, len, offset));
/* Handle any exceptions. */
if (result_obj == nullptr)
diff --git a/gdb/testsuite/gdb.python/py-disasm.exp b/gdb/testsuite/gdb.python/py-disasm.exp
index f2f9225168a..9d0f6ec1d01 100644
--- a/gdb/testsuite/gdb.python/py-disasm.exp
+++ b/gdb/testsuite/gdb.python/py-disasm.exp
@@ -65,7 +65,7 @@ proc py_remove_all_disassemblers {} {
#
# Each different disassembler tests some different feature of the
# Python disassembler API.
-set nop "(nop|nop\t0)"
+set nop "(nop|nop\t0|[string_to_regexp nop\t{0}])"
set unknown_error_pattern "unknown disassembler error \\(error = -1\\)"
set addr_pattern "\r\n=> ${curr_pc_pattern} <\[^>\]+>:\\s+"
set base_pattern "${addr_pattern}${nop}"
diff --git a/gdb/testsuite/gdb.python/py-disasm.py b/gdb/testsuite/gdb.python/py-disasm.py
index 67ba6756ea9..6a39b0764e6 100644
--- a/gdb/testsuite/gdb.python/py-disasm.py
+++ b/gdb/testsuite/gdb.python/py-disasm.py
@@ -46,7 +46,7 @@ def check_building_disassemble_result():
def is_nop(s):
- return s == "nop" or s == "nop\t0"
+ return s == "nop" or s == "nop\t0" or s == "nop\t{0}"
# Remove all currently registered disassemblers.
base-commit: 22383ac8031b0e626e8ecd62e4378266065d067c
--
2.35.3

70
gdb-python-make-gdb.unwindinfo.add_saved_register-mo-fixup.patch Normal file
View File

@ -0,0 +1,70 @@
From fc73000faa1798573090994167b7e2d451c211db Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Fri, 10 May 2024 08:46:21 +0200
Subject: [PATCH] [gdb/python] Make gdb.UnwindInfo.add_saved_register more
robust (fixup)
In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register
more robust") I added this code in unwind_infopy_add_saved_register:
...
if (value->optimized_out () || !value->entirely_available ())
...
which may throw c++ exceptions.
This needs to be caught and transformed into a python exception.
Fix this by using GDB_PY_HANDLE_EXCEPTION.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
(cherry picked from commit 408bc9c5fc757bd4b8adb1c3d54ecd672beaedb7)
---
gdb/python/py-unwind.c | 26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/gdb/python/py-unwind.c b/gdb/python/py-unwind.c
index 471eb851674..e57c8c1adcf 100644
--- a/gdb/python/py-unwind.c
+++ b/gdb/python/py-unwind.c
@@ -354,16 +354,24 @@ unwind_infopy_add_saved_register (PyObject *self, PyObject *args, PyObject *kw)
return nullptr;
}
- if (value->optimized_out () || !value->entirely_available ())
+
+ try
+ {
+ if (value->optimized_out () || !value->entirely_available ())
+ {
+ /* If we allow this value to be registered here, pyuw_sniffer is going
+ to run into an exception when trying to access its contents.
+ Throwing an exception here just puts a burden on the user to
+ implement the same checks on the user side. We could return False
+ here and True otherwise, but again that might require changes in
+ user code. So, handle this with minimal impact for the user, while
+ improving robustness: silently ignore the register/value pair. */
+ Py_RETURN_NONE;
+ }
+ }
+ catch (const gdb_exception &except)
{
- /* If we allow this value to be registered here, pyuw_sniffer is going
- to run into an exception when trying to access its contents.
- Throwing an exception here just puts a burden on the user to
- implement the same checks on the user side. We could return False
- here and True otherwise, but again that might require changes in user
- code. So, handle this with minimal impact for the user, while
- improving robustness: silently ignore the register/value pair. */
- Py_RETURN_NONE;
+ GDB_PY_HANDLE_EXCEPTION (except);
}
gdbpy_ref<> new_value = gdbpy_ref<>::new_reference (pyo_reg_value);
base-commit: a6f598be3d0477c5c59bd490573a5d457949658e
--
2.35.3

76
gdb-tdep-fix-gdb.base-watchpoint-running-on-arm-ppc6.patch Normal file
View File

@ -0,0 +1,76 @@
From 1e64a66f72c79874016e78a4672b85cdeb506b9f Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Tue, 4 Jun 2024 09:30:03 +0000
Subject: [PATCH] [gdb/tdep] Fix gdb.base/watchpoint-running on
{arm,ppc64le}-linux
When running test-case gdb.base/watchpoint-running on ppc64le-linux, we get:
...
(gdb) watch global_var^M
warning: Error when detecting the debug register interface. \
Debug registers will be unavailable.^M
Watchpoint 2: global_var^M
(gdb) FAIL: $exp: all-stop: hardware: watch global_var
FAIL: $exp: all-stop: hardware: watchpoint hit (timeout)
...
The problem is that ppc_linux_dreg_interface::detect fails to detect the
hardware watchpoint interface, because the calls to ptrace return with errno
set to ESRCH.
This is a feature of ptrace: if a call is done while the tracee is not
ptrace-stopped, it returns ESRCH.
Indeed, in the test-case "watch global_var" is executed while the inferior is
running, and that triggers the first call to ppc_linux_dreg_interface::detect.
And because the detection failure is cached, subsequent attempts at setting
hardware watchpoints will also fail, even if the tracee is ptrace-stopped.
Fix this by calling target_can_use_hardware_watchpoint from
linux_init_ptrace_procfs, which is called from both:
- linux_nat_target::post_attach, and
- linux_nat_target::post_startup_inferior.
By fixing this here, we also fix the same problem for arm-linux.
Tested on ppc64le-linux and arm-linux.
PR tdep/31834
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834
PR tdep/31705
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705
(cherry picked from commit bbc92bfbf25ad42548100e31e491ed3c32fbfa3e)
---
gdb/linux-nat.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index c8991cc3da4..47d74d27e11 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -385,6 +385,18 @@ linux_init_ptrace_procfs (pid_t pid, int attached)
linux_ptrace_init_warnings ();
linux_proc_init_warnings ();
proc_mem_file_is_writable ();
+
+ /* Some targets (for instance ppc and arm) may call ptrace to answer a
+ target_can_use_hardware_watchpoint query, and cache the result. However,
+ the ptrace call will fail with errno ESRCH if the tracee is not
+ ptrace-stopped, making the query fail. And if the caching mechanism does
+ not disregard an ESRCH result, all subsequent queries will also fail.
+ Call it now, where we known the tracee is ptrace-stopped.
+
+ Other targets (for instance aarch64) do the relevant ptrace call and
+ caching in their implementation of post_attach and post_startup_inferior,
+ in which case this call is expected to have no effect. */
+ target_can_use_hardware_watchpoint (bp_hardware_watchpoint, 1, 0);
}
linux_nat_target::~linux_nat_target ()
base-commit: a6800d9c8145f25001dd39afc3571e3350573e81
--
2.35.3

95
gdb-testsuite-fix-gdb.fortran-array-bounds.exp-on-ar.patch Normal file
View File

@ -0,0 +1,95 @@
From a6f598be3d0477c5c59bd490573a5d457949658e Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Fri, 7 Jun 2024 08:12:34 +0200
Subject: [PATCH] [gdb/testsuite] Fix gdb.fortran/array-bounds.exp on arm
When running test-case gdb.fortran/array-bounds.exp on arm-linux, we run into:
...
(gdb) print &foo^M
$1 = (PTR TO -> ( real(kind=4) (0:1) )) 0xfffef008^M
(gdb) FAIL: gdb.fortran/array-bounds.exp: print &foo
print &bar^M
$2 = (PTR TO -> ( real(kind=4) (-1:0) )) 0xfffef010^M
(gdb) FAIL: gdb.fortran/array-bounds.exp: print &bar
...
This is due to gcc PR debug/54934.
The test-case contains a kfail for this, which is only activated for
x86_64/i386.
Fix this by enabling the kfail for all ilp32 targets.
Also:
- change the kfail into an xfail, because gdb is not at fault here, and
- limit the xfail to the gfortran compiler.
Tested on arm-linux.
(cherry picked from commit f9478936896ada7786e8d68622f6e6ff78b97b0d)
---
gdb/testsuite/gdb.fortran/array-bounds.exp | 45 +++++++++++++++-------
1 file changed, 31 insertions(+), 14 deletions(-)
diff --git a/gdb/testsuite/gdb.fortran/array-bounds.exp b/gdb/testsuite/gdb.fortran/array-bounds.exp
index e3f2603a118..a9d6011aed4 100644
--- a/gdb/testsuite/gdb.fortran/array-bounds.exp
+++ b/gdb/testsuite/gdb.fortran/array-bounds.exp
@@ -31,21 +31,38 @@ if {![fortran_runto_main]} {
return
}
-# Convenience proc to setup for KFAIL
-proc kfail_if {exp bugid triplet} {
- if {$exp} {
- setup_kfail $bugid $triplet
+# GCC outputs incorrect range debug info for -m32, gcc PR debug/54934.
+set expect_xfail \
+ [expr \
+ [test_compiler_info {gfortran-*} f90] \
+ && [is_ilp32_target]]
+
+set re_ok [string_to_regexp (4294967296:4294967297)]
+set re_xfail [string_to_regexp (0:1)]
+gdb_test_multiple "print &foo" "" {
+ -re -wrap $re_ok.* {
+ pass $gdb_test_name
+ }
+ -re -wrap $re_xfail.* {
+ if { $expect_xfail } {
+ xfail $gdb_test_name
+ } else {
+ fail $gdb_test_name
+ }
}
}
-# GCC outputs incorrect range debug info for -m32.
-set expect_fail false
-if {[is_ilp32_target] && ([istarget "i\[34567\]86-*-linux*"]
- || [istarget "x86_64-*-linux*"])} {
- set expect_fail true
+set re_ok [string_to_regexp (-4294967297:-4294967296)]
+set re_xfail [string_to_regexp (-1:0)]
+gdb_test_multiple "print &bar" "" {
+ -re -wrap $re_ok.* {
+ pass $gdb_test_name
+ }
+ -re -wrap $re_xfail.* {
+ if { $expect_xfail } {
+ xfail $gdb_test_name
+ } else {
+ fail $gdb_test_name
+ }
+ }
}
-
-kfail_if $expect_fail "gcc/54934" "*-*-*"
-gdb_test "print &foo" {.*\(4294967296:4294967297\).*}
-kfail_if $expect_fail "gcc/54934" "*-*-*"
-gdb_test "print &bar" {.*\(-4294967297:-4294967296\).*}
base-commit: 4c7dab250c3581e691c2da87395e80244074d8bf
--
2.35.3

13
gdb.changes
View File

@ -1,3 +1,16 @@
-------------------------------------------------------------------
Thu Jun 13 07:07:11 UTC 2024 - Tom de Vries <tdevries@suse.com>
- Patches dropped:
* fix-gdb.threads-threads-after-exec.exp-race.patch
* add-maint-info-linux-lwps-command.patch
- Patches added:
* gdb-python-fix-gdb.python-py-disasm.exp-on-arm-linux.patch
* gdb-testsuite-fix-gdb.fortran-array-bounds.exp-on-ar.patch
* gdb-python-make-gdb.unwindinfo.add_saved_register-mo-fixup.patch
* exp-redo-cast-handling-for-indirection.patch
* gdb-tdep-fix-gdb.base-watchpoint-running-on-arm-ppc6.patch
-------------------------------------------------------------------
Sat Jun 1 06:10:43 UTC 2024 - Tom de Vries <tdevries@suse.com>

17
gdb.spec
View File

@ -332,16 +332,19 @@ Patch2063: gdb-symtab-workaround-pr-gas-31115.patch
Patch2064: gdb-arm-remove-tpidruro-register-from-non-freebsd-ta.patch
Patch2065: gdb-tdep-fix-catching-syscall-execve-exit-for-arm.patch
Patch2066: gdb-arm-fix-epilogue-frame-id.patch
Patch2068: add-maint-info-linux-lwps-command.patch
Patch2069: fix-gdb.threads-threads-after-exec.exp-race.patch
Patch2070: rs6000-unwind-on-each-instruction-fix.patch
Patch2071: gdb-python-make-gdb.unwindinfo.add_saved_register-mo.patch
Patch2072: gdb-arm-remove-thumb-bit-in-arm_adjust_breakpoint_ad.patch
Patch2073: gdb-build-fix-gdbserver-linux-aarch64-low.cc-build.patch
Patch2074: powerpc-fix-test-gdb.ada-finish-large.exp.patch
Patch2075: gdb-python-make-gdb.unwindinfo.add_saved_register-mo-fixup.patch
Patch2076: gdb-exp-redo-cast-handling-for-indirection.patch
# Backports from master, not yet available in next release (GDB 16).
Patch2090: gdb-python-fix-gdb.python-py-disasm.exp-on-arm-linux.patch
Patch2091: gdb-testsuite-fix-gdb.fortran-array-bounds.exp-on-ar.patch
#
# Backport from gdb-patches
@ -356,6 +359,8 @@ Patch2102: gdb-cli-add-ignore-errors-command.patch
Patch2103: gdb-testsuite-fix-error-in-gdb.server-server-kill-py.patch
# https://sourceware.org/pipermail/gdb-patches/2024-May/209504.html
Patch2104: gdb-testsuite-fix-timeout-in-gdb.tui-resize-2.exp.patch
# https://sourceware.org/pipermail/gdb-patches/2024-June/209736.html
Patch2105: gdb-tdep-fix-gdb.base-watchpoint-running-on-arm-ppc6.patch
# https://sourceware.org/pipermail/gdb-patches/2023-December/205054.html
Patch2120: gdb-symtab-refactor-condition-in-scan_attributes.patch
@ -806,19 +811,23 @@ find -name "*.info*"|xargs rm -f
%patch -P 2064 -p1
%patch -P 2065 -p1
%patch -P 2066 -p1
%patch -P 2068 -p1
%patch -P 2069 -p1
%patch -P 2070 -p1
%patch -P 2071 -p1
%patch -P 2072 -p1
%patch -P 2073 -p1
%patch -P 2074 -p1
%patch -P 2075 -p1
%patch -P 2076 -p1
%patch -P 2090 -p1
%patch -P 2091 -p1
%patch -P 2100 -p1
%patch -P 2101 -p1
%patch -P 2102 -p1
%patch -P 2103 -p1
%patch -P 2104 -p1
%patch -P 2105 -p1
%patch -P 2120 -p1
%patch -P 2121 -p1