forked from Imagelibrary/binutils-gdb
2dc3457a45
When GDB fails to test the condition of a conditional breakpoint, for whatever reason, the error message looks like this: (gdb) break foo if (*(int *) 0) == 1 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Error in testing breakpoint condition: Cannot access memory at address 0x0 Breakpoint 1, foo () at bpcond.c:11 11 int a = 32; (gdb) The line I'm interested in for this commit is this one: Error in testing breakpoint condition: In the case above we can figure out that the problematic breakpoint was #1 because in the final line of the message GDB reports the stop at breakpoint #1. However, in the next few patches I plan to change this. In some cases I don't think it makes sense for GDB to report the stop as being at breakpoint #1, consider this case: (gdb) list some_func 1 int 2 some_func () 3 { 4 int *p = 0; 5 return *p; 6 } 7 8 void 9 foo () 10 { (gdb) break foo if (some_func ()) Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Program received signal SIGSEGV, Segmentation fault. 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; Error in testing breakpoint condition: The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on". Evaluation of the expression containing the function (some_func) will be abandoned. When the function is done executing, GDB will silently stop. Program received signal SIGSEGV, Segmentation fault. Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5 5 return *p; (gdb) Notice that, the final lines of output reports the stop as being at breakpoint #1, even though the inferior in not located within some_func, and it's certainly not located at the breakpoint location. I find this behaviour confusing, and propose that this should be changed. However, if I make that change then every reference to breakpoint #1 will be lost from the error message. So, in this commit, in preparation for the later commits, I propose to change the 'Error in testing breakpoint condition:' line to this: Error in testing condition for breakpoint NUMBER: where NUMBER will be filled in as appropriate. Here's the first example with the updated error: (gdb) break foo if (*(int *) 0) == 0 Breakpoint 1 at 0x40111e: file bpcond.c, line 11. (gdb) r Starting program: /tmp/bpcond Error in testing condition for breakpoint 1: Cannot access memory at address 0x0 Breakpoint 1, foo () at bpcond.c:11 11 int a = 32; (gdb) The breakpoint number does now appear twice in the output, but I don't see that as a negative. This commit just changes the one line of the error, and updates the few tests that either included the old error in comments, or actually checked for the error in the expected output. As the only test that checked the line I modified is a Python test, I've added a new test that doesn't rely on Python that checks the error message in detail. While working on the new test, I spotted that it would fail when run with native-gdbserver and native-extended-gdbserver target boards. This turns out to be due to a gdbserver bug. To avoid cluttering this commit I've added a work around to the new test script so that the test passes for the remote boards, in the next few commits I will fix gdbserver, and update the test script to remove the work around.
55 lines
1.9 KiB
Plaintext
55 lines
1.9 KiB
Plaintext
# Copyright 2015-2023 Free Software Foundation, Inc.
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
# it under the terms of the GNU General Public License as published by
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
# (at your option) any later version.
|
|
#
|
|
# This program is distributed in the hope that it will be useful,
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
# GNU General Public License for more details.
|
|
#
|
|
# You should have received a copy of the GNU General Public License
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
# Regression test for PR19388. Make sure we can access $_siginfo in a
|
|
# "catch signal" condition. A buggy GDB would fail with:
|
|
#
|
|
# (gdb) continue
|
|
# Continuing.
|
|
# Error in testing condition for breakpoint NUM:
|
|
# Selected thread is running.
|
|
#
|
|
# Catchpoint 3 (signal SIGUSR1), 0x0000003615e35877 in __GI_raise (sig=10) at raise.c:56
|
|
# 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
|
|
# (gdb) FAIL: gdb.base/catch-signal-siginfo-cond.exp: continue
|
|
|
|
require {!target_info exists gdb,nosignals}
|
|
|
|
require supports_get_siginfo_type
|
|
|
|
standard_testfile
|
|
|
|
if { [prepare_for_testing "failed to prepare" "${testfile}" $srcfile {debug}] } {
|
|
return -1
|
|
}
|
|
|
|
if {![runto_main]} {
|
|
return -1
|
|
}
|
|
|
|
gdb_breakpoint [gdb_get_line_number "set breakpoint here"]
|
|
|
|
gdb_test "catch signal"
|
|
|
|
# It's OK to refer to standard Unix signal numbers 1-15 by number.
|
|
|
|
# SIGUSR1 == 10. The catchpoint should not cause a stop.
|
|
gdb_test "condition \$bpnum \$_siginfo.si_signo == 11"
|
|
gdb_test "continue" "set breakpoint here.*" "continue: catchpoint does not trigger"
|
|
|
|
# This time the catchpoint should cause a stop.
|
|
gdb_test "condition \$bpnum \$_siginfo.si_signo == 10"
|
|
gdb_test "continue" "Catchpoint .*signal SIGUSR1.*" "continue: catchpoint triggers"
|