2014-06-03 19:46:46 +08:00
|
|
|
# Copyright (C) 2014 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/>.
|
|
|
|
|
|
|
|
# Test that GDB doesn't get confused in the following scenario
|
|
|
|
# (PR breakpoints/17000). Say, we have this program:
|
|
|
|
#
|
|
|
|
# => 0xff000001 INSN1
|
|
|
|
# 0xff000002 INSN2
|
|
|
|
#
|
|
|
|
# The PC currently points at INSN1.
|
|
|
|
#
|
|
|
|
# 1 - User sets a breakpoint at 0xff000002 (INSN2).
|
|
|
|
#
|
|
|
|
# 2 - User steps. On software single-step archs, this sets a software
|
|
|
|
# single-step breakpoint at 0xff000002 (INSN2) too.
|
|
|
|
#
|
|
|
|
# 3 - User deletes breakpoint (INSN2) before the single-step finishes.
|
|
|
|
#
|
|
|
|
# 4 - The single-step finishes, and GDB removes the single-step
|
|
|
|
# breakpoint.
|
|
|
|
|
|
|
|
standard_testfile
|
|
|
|
|
|
|
|
if {[prepare_for_testing "failed to prepare" $testfile $srcfile debug]} {
|
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
|
|
|
if ![runto_main] {
|
|
|
|
fail "Can't run to main"
|
|
|
|
return 0
|
|
|
|
}
|
|
|
|
|
2014-06-03 21:04:48 +08:00
|
|
|
delete_breakpoints
|
|
|
|
|
|
|
|
# With the all-stop RSP, we can't talk to the target while it's
|
|
|
|
# running, until we get back the stop reply. If not using single-step
|
|
|
|
# breakpoints, then the "del" in stepi_del_break below will try to
|
|
|
|
# delete the user breakpoint from the target, which will fail, with
|
|
|
|
# "Cannot execute this command while the target is running.". On
|
|
|
|
# software single-step targets, that del shouldn't trigger any RSP
|
sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux.
I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I
sometimes still see an int3 in the disassembly:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0
disassemble test
Dump of assembler code for function test:
0x0000000000400590 <+0>: push %rbp
0x0000000000400591 <+1>: mov %rsp,%rbp
0x0000000000400594 <+4>: nop
=> 0x0000000000400595 <+5>: int3
0x0000000000400596 <+6>: pop %rbp
0x0000000000400597 <+7>: retq
End of assembler dump.
(gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches
Enabling infrun/target debug logs, we can see the problem.
Simplified, that's:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
stepi_del_break
infrun: clear_proceed_status_thread (process 25311)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594
LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread)
target_resume (25311, step, 0)
native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG]
0x400595 is the address of the breakpoint, and "= 0" is
TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to
remove the breakpoint, but failing.
The problem is that we had just resumed the target and the native
GNU/Linux target can't read memory off of a running thread. Most of
the time, we get "lucky", because we manage to read memory before the
kernel actually schedules the target to run.
So just give up and skip the test on any target that uses hardware
stepping, not just remote targets.
gdb/testsuite/
2014-06-06 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step)
in target debug output instead of looking at RSP packets,
disabling the test on any target that uses hardware stepping.
Update comments.
2014-06-07 02:59:21 +08:00
|
|
|
# traffic. Hardware-step targets that can't access memory while the
|
|
|
|
# target is running, either remote or native, are likewise affected.
|
|
|
|
# So we just skip the test if not using software single-stepping. We
|
2014-07-30 03:31:00 +08:00
|
|
|
# detect that by looking for 'to_resume (..., step)' in "debug
|
sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux.
I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I
sometimes still see an int3 in the disassembly:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0
disassemble test
Dump of assembler code for function test:
0x0000000000400590 <+0>: push %rbp
0x0000000000400591 <+1>: mov %rsp,%rbp
0x0000000000400594 <+4>: nop
=> 0x0000000000400595 <+5>: int3
0x0000000000400596 <+6>: pop %rbp
0x0000000000400597 <+7>: retq
End of assembler dump.
(gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches
Enabling infrun/target debug logs, we can see the problem.
Simplified, that's:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
stepi_del_break
infrun: clear_proceed_status_thread (process 25311)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594
LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread)
target_resume (25311, step, 0)
native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG]
0x400595 is the address of the breakpoint, and "= 0" is
TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to
remove the breakpoint, but failing.
The problem is that we had just resumed the target and the native
GNU/Linux target can't read memory off of a running thread. Most of
the time, we get "lucky", because we manage to read memory before the
kernel actually schedules the target to run.
So just give up and skip the test on any target that uses hardware
stepping, not just remote targets.
gdb/testsuite/
2014-06-06 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step)
in target debug output instead of looking at RSP packets,
disabling the test on any target that uses hardware stepping.
Update comments.
2014-06-07 02:59:21 +08:00
|
|
|
# target" output.
|
2014-06-03 21:04:48 +08:00
|
|
|
|
|
|
|
# Probe for software single-step breakpoint use.
|
sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux.
I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I
sometimes still see an int3 in the disassembly:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0
disassemble test
Dump of assembler code for function test:
0x0000000000400590 <+0>: push %rbp
0x0000000000400591 <+1>: mov %rsp,%rbp
0x0000000000400594 <+4>: nop
=> 0x0000000000400595 <+5>: int3
0x0000000000400596 <+6>: pop %rbp
0x0000000000400597 <+7>: retq
End of assembler dump.
(gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches
Enabling infrun/target debug logs, we can see the problem.
Simplified, that's:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
stepi_del_break
infrun: clear_proceed_status_thread (process 25311)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594
LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread)
target_resume (25311, step, 0)
native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG]
0x400595 is the address of the breakpoint, and "= 0" is
TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to
remove the breakpoint, but failing.
The problem is that we had just resumed the target and the native
GNU/Linux target can't read memory off of a running thread. Most of
the time, we get "lucky", because we manage to read memory before the
kernel actually schedules the target to run.
So just give up and skip the test on any target that uses hardware
stepping, not just remote targets.
gdb/testsuite/
2014-06-06 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step)
in target debug output instead of looking at RSP packets,
disabling the test on any target that uses hardware stepping.
Update comments.
2014-06-07 02:59:21 +08:00
|
|
|
|
|
|
|
gdb_test_no_output "set debug target 1"
|
|
|
|
set hardware_step 0
|
|
|
|
set test "probe target hardware step"
|
2014-06-03 21:04:48 +08:00
|
|
|
gdb_test_multiple "si" $test {
|
2014-07-30 03:31:00 +08:00
|
|
|
-re "to_resume \\(\[^\r\n\]+, step, .*$gdb_prompt $" {
|
sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux.
I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I
sometimes still see an int3 in the disassembly:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0
disassemble test
Dump of assembler code for function test:
0x0000000000400590 <+0>: push %rbp
0x0000000000400591 <+1>: mov %rsp,%rbp
0x0000000000400594 <+4>: nop
=> 0x0000000000400595 <+5>: int3
0x0000000000400596 <+6>: pop %rbp
0x0000000000400597 <+7>: retq
End of assembler dump.
(gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches
Enabling infrun/target debug logs, we can see the problem.
Simplified, that's:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
stepi_del_break
infrun: clear_proceed_status_thread (process 25311)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594
LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread)
target_resume (25311, step, 0)
native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG]
0x400595 is the address of the breakpoint, and "= 0" is
TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to
remove the breakpoint, but failing.
The problem is that we had just resumed the target and the native
GNU/Linux target can't read memory off of a running thread. Most of
the time, we get "lucky", because we manage to read memory before the
kernel actually schedules the target to run.
So just give up and skip the test on any target that uses hardware
stepping, not just remote targets.
gdb/testsuite/
2014-06-06 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step)
in target debug output instead of looking at RSP packets,
disabling the test on any target that uses hardware stepping.
Update comments.
2014-06-07 02:59:21 +08:00
|
|
|
set hardware_step 1
|
2014-06-03 21:04:48 +08:00
|
|
|
pass $test
|
|
|
|
}
|
|
|
|
-re "$gdb_prompt $" {
|
|
|
|
pass $test
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
sss-bp-on-user-bp-2.exp sometimes fails on native GNU/Linux.
I noticed that sss-bp-on-user-bp-2.exp is racy on native GNU/Linux. I
sometimes still see an int3 in the disassembly:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: set debug target 0
disassemble test
Dump of assembler code for function test:
0x0000000000400590 <+0>: push %rbp
0x0000000000400591 <+1>: mov %rsp,%rbp
0x0000000000400594 <+4>: nop
=> 0x0000000000400595 <+5>: int3
0x0000000000400596 <+6>: pop %rbp
0x0000000000400597 <+7>: retq
End of assembler dump.
(gdb) FAIL: gdb.base/sss-bp-on-user-bp-2.exp: before/after disassembly matches
Enabling infrun/target debug logs, we can see the problem.
Simplified, that's:
(gdb) PASS: gdb.base/sss-bp-on-user-bp-2.exp: define stepi_del_break
stepi_del_break
infrun: clear_proceed_status_thread (process 25311)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 25311] at 0x400594
LLR: PTRACE_SINGLESTEP process 25311, 0 (resume event thread)
target_resume (25311, step, 0)
native:target_xfer_partial (3, (null), 0x0, 0x32dce4c, 0x400595, 1) = 0, 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG]
0x400595 is the address of the breakpoint, and "= 0" is
TARGET_XFER_EOF. That's default_memory_remove_breakpoint trying to
remove the breakpoint, but failing.
The problem is that we had just resumed the target and the native
GNU/Linux target can't read memory off of a running thread. Most of
the time, we get "lucky", because we manage to read memory before the
kernel actually schedules the target to run.
So just give up and skip the test on any target that uses hardware
stepping, not just remote targets.
gdb/testsuite/
2014-06-06 Pedro Alves <palves@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Look for target_resume(step)
in target debug output instead of looking at RSP packets,
disabling the test on any target that uses hardware stepping.
Update comments.
2014-06-07 02:59:21 +08:00
|
|
|
if { $hardware_step } {
|
|
|
|
unsupported "target doesn't use software single-stepping"
|
2014-06-03 21:04:48 +08:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2014-07-29 02:53:35 +08:00
|
|
|
gdb_test "set debug target 0" "->to_log_command.*\\)"
|
2014-06-03 21:04:48 +08:00
|
|
|
|
2014-06-03 19:46:46 +08:00
|
|
|
set line_re "\[^\r\n\]*"
|
|
|
|
|
|
|
|
gdb_test "b test:label" "Breakpoint .*"
|
|
|
|
gdb_continue_to_breakpoint "run past setup"
|
|
|
|
delete_breakpoints
|
|
|
|
|
|
|
|
# So we can precisely control breakpoint insertion order.
|
|
|
|
gdb_test_no_output "set breakpoint always-inserted on"
|
|
|
|
|
|
|
|
# Capture disassembly output. PREFIX is used as test prefix. The
|
|
|
|
# current instruction indicator (=>) is stripped away.
|
|
|
|
proc disassemble { prefix } {
|
|
|
|
with_test_prefix "$prefix" {
|
|
|
|
set output [capture_command_output "disassemble test" ""]
|
|
|
|
return [string map {"=>" " "} $output]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Issue a stepi and immediately delete the user breakpoint that is set
|
|
|
|
# at the same address as the software single-step breakpoint. Do this
|
|
|
|
# in a user defined command, so that the stepi's trap doesn't have a
|
|
|
|
# chance to be handled before further input is processed. We then
|
|
|
|
# compare before/after disassembly. GDB should be able to handle
|
|
|
|
# deleting the user breakpoint before deleting the single-step
|
|
|
|
# breakpoint. E.g., we shouldn't see breakpoint instructions in the
|
|
|
|
# disassembly.
|
|
|
|
|
|
|
|
set disasm_before [disassemble "before"]
|
|
|
|
|
|
|
|
gdb_test "b test:label2" ".*" "set breakpoint where si will land"
|
|
|
|
|
|
|
|
set test "define stepi_del_break"
|
|
|
|
gdb_test_multiple $test $test {
|
|
|
|
-re "Type commands for definition of \"stepi_del_break\".\r\nEnd with a line saying just \"end\".\r\n>$" {
|
|
|
|
gdb_test "si&\ndel \$bpnum\nend" "" $test
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
set command "stepi_del_break"
|
|
|
|
set test $command
|
|
|
|
gdb_test_multiple $command $test {
|
|
|
|
-re "^$command\r\n$gdb_prompt " {
|
|
|
|
# Note no end anchor, because "si&" finishes and prints the
|
|
|
|
# current frame/line after the prompt is printed.
|
|
|
|
pass $test
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
# Now consume the output of the finished "si&".
|
|
|
|
set test "si& finished"
|
|
|
|
gdb_test_multiple "" $test {
|
|
|
|
-re "must be a single line \\\*/\r\n" {
|
|
|
|
pass $test
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
set disasm_after [disassemble "after"]
|
|
|
|
|
|
|
|
set test "before/after disassembly matches"
|
|
|
|
if ![string compare $disasm_before $disasm_after] {
|
|
|
|
pass $test
|
|
|
|
} else {
|
|
|
|
fail $test
|
|
|
|
}
|