From 9f8d02b6db0dad8d2ee9415ca17fc2dc08e9b0c04861c0a81c16aa1bab941ae8 Mon Sep 17 00:00:00 2001 From: Tom de Vries Date: Thu, 13 Jun 2024 09:00:01 +0000 Subject: [PATCH] - 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 OBS-URL: https://build.opensuse.org/package/show/devel:gcc/gdb?expand=0&rev=389 --- add-maint-info-linux-lwps-command.patch | 108 --------------- ....threads-threads-after-exec.exp-race.patch | 97 -------------- ...p-redo-cast-handling-for-indirection.patch | 86 ++++++++++++ ...db.python-py-disasm.exp-on-arm-linux.patch | 125 ++++++++++++++++++ ...windinfo.add_saved_register-mo-fixup.patch | 70 ++++++++++ ....base-watchpoint-running-on-arm-ppc6.patch | 76 +++++++++++ ...x-gdb.fortran-array-bounds.exp-on-ar.patch | 95 +++++++++++++ gdb.changes | 13 ++ gdb.spec | 17 ++- 9 files changed, 478 insertions(+), 209 deletions(-) delete mode 100644 add-maint-info-linux-lwps-command.patch delete mode 100644 fix-gdb.threads-threads-after-exec.exp-race.patch create mode 100644 gdb-exp-redo-cast-handling-for-indirection.patch create mode 100644 gdb-python-fix-gdb.python-py-disasm.exp-on-arm-linux.patch create mode 100644 gdb-python-make-gdb.unwindinfo.add_saved_register-mo-fixup.patch create mode 100644 gdb-tdep-fix-gdb.base-watchpoint-running-on-arm-ppc6.patch create mode 100644 gdb-testsuite-fix-gdb.fortran-array-bounds.exp-on-ar.patch diff --git a/add-maint-info-linux-lwps-command.patch b/add-maint-info-linux-lwps-command.patch deleted file mode 100644 index 7798dc2..0000000 --- a/add-maint-info-linux-lwps-command.patch +++ /dev/null @@ -1,108 +0,0 @@ -From ab0396671d0d5f05573837171e0f2180ab194411 Mon Sep 17 00:00:00 2001 -From: Andrew Burgess -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 -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 - diff --git a/fix-gdb.threads-threads-after-exec.exp-race.patch b/fix-gdb.threads-threads-after-exec.exp-race.patch deleted file mode 100644 index 89e4a66..0000000 --- a/fix-gdb.threads-threads-after-exec.exp-race.patch +++ /dev/null @@ -1,97 +0,0 @@ -From 800e56a120419b457ebda18c5478ebfea99f9b3a Mon Sep 17 00:00:00 2001 -From: Pedro Alves -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 - diff --git a/gdb-exp-redo-cast-handling-for-indirection.patch b/gdb-exp-redo-cast-handling-for-indirection.patch new file mode 100644 index 0000000..3000d9b --- /dev/null +++ b/gdb-exp-redo-cast-handling-for-indirection.patch @@ -0,0 +1,86 @@ +From a6800d9c8145f25001dd39afc3571e3350573e81 Mon Sep 17 00:00:00 2001 +From: Tom de Vries +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 + +[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 . + +-# 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 + diff --git a/gdb-python-fix-gdb.python-py-disasm.exp-on-arm-linux.patch b/gdb-python-fix-gdb.python-py-disasm.exp-on-arm-linux.patch new file mode 100644 index 0000000..a8e39f6 --- /dev/null +++ b/gdb-python-fix-gdb.python-py-disasm.exp-on-arm-linux.patch @@ -0,0 +1,125 @@ +From 4c7dab250c3581e691c2da87395e80244074d8bf Mon Sep 17 00:00:00 2001 +From: Tom de Vries +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 : 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 +Approved-By: Tom Tromey + +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 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 + diff --git a/gdb-python-make-gdb.unwindinfo.add_saved_register-mo-fixup.patch b/gdb-python-make-gdb.unwindinfo.add_saved_register-mo-fixup.patch new file mode 100644 index 0000000..757228c --- /dev/null +++ b/gdb-python-make-gdb.unwindinfo.add_saved_register-mo-fixup.patch @@ -0,0 +1,70 @@ +From fc73000faa1798573090994167b7e2d451c211db Mon Sep 17 00:00:00 2001 +From: Tom de Vries +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 + +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 + diff --git a/gdb-tdep-fix-gdb.base-watchpoint-running-on-arm-ppc6.patch b/gdb-tdep-fix-gdb.base-watchpoint-running-on-arm-ppc6.patch new file mode 100644 index 0000000..74340f0 --- /dev/null +++ b/gdb-tdep-fix-gdb.base-watchpoint-running-on-arm-ppc6.patch @@ -0,0 +1,76 @@ +From 1e64a66f72c79874016e78a4672b85cdeb506b9f Mon Sep 17 00:00:00 2001 +From: Tom de Vries +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 + diff --git a/gdb-testsuite-fix-gdb.fortran-array-bounds.exp-on-ar.patch b/gdb-testsuite-fix-gdb.fortran-array-bounds.exp-on-ar.patch new file mode 100644 index 0000000..fce13ed --- /dev/null +++ b/gdb-testsuite-fix-gdb.fortran-array-bounds.exp-on-ar.patch @@ -0,0 +1,95 @@ +From a6f598be3d0477c5c59bd490573a5d457949658e Mon Sep 17 00:00:00 2001 +From: Tom de Vries +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 + diff --git a/gdb.changes b/gdb.changes index 8ee3fd4..8b56ad3 100644 --- a/gdb.changes +++ b/gdb.changes @@ -1,3 +1,16 @@ +------------------------------------------------------------------- +Thu Jun 13 07:07:11 UTC 2024 - Tom de Vries + +- 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 diff --git a/gdb.spec b/gdb.spec index caa76b0..eacbdc0 100644 --- a/gdb.spec +++ b/gdb.spec @@ -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