binutils-gdb/gdb/testsuite/gdb.threads/next-fork-other-thread.exp
Simon Marchi 27f9f64975 gdb: resume ongoing step after handling fork or vfork
The test introduced by this patch would fail in this configuration, with
the native-gdbserver or native-extended-gdbserver boards:

    FAIL: gdb.threads/next-fork-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=2: next to for loop

The problem is that the step operation is forgotten when handling the
fork/vfork.  With "debug infrun" and "debug remote", it looks like this
(some lines omitted for brevity).  We do the next:

    [infrun] proceed: enter
      [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
      [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154304.0] at 0x5555555553bf
      [infrun] do_target_resume: resume_ptid=4154304.0.0, step=1, sig=GDB_SIGNAL_0
      [remote] Sending packet: $vCont;r5555555553bf,5555555553c4:p3f63c0.3f63c0;c:p3f63c0.-1#cd
    [infrun] proceed: exit

We then handle a fork event:

    [infrun] fetch_inferior_event: enter
      [remote] wait: enter
        [remote] Packet received: T05fork:p3f63ee.3f63ee;06:0100000000000000;07:b08e59f6ff7f0000;10:bf60e8f7ff7f0000;thread:p3f63c0.3f63c6;core:17;
      [remote] wait: exit
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   4154304.4154310.0 [Thread 4154304.4154310],
      [infrun] print_target_wait_results:   status->kind = FORKED, child_ptid = 4154350.4154350.0
      [infrun] handle_inferior_event: status->kind = FORKED, child_ptid = 4154350.4154350.0
      [remote] Sending packet: $D;3f63ee#4b
      [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [4154304.4154310.0] at 0x7ffff7e860bf
      [infrun] do_target_resume: resume_ptid=4154304.0.0, step=0, sig=GDB_SIGNAL_0
      [remote] Sending packet: $vCont;c:p3f63c0.-1#73
    [infrun] fetch_inferior_event: exit

In the first snippet, we resume the stepping thread with the range-stepping (r)
vCont command.  But after handling the fork (detaching the fork child), we
resumed the whole process freely.  The stepping thread, which was paused by
GDBserver while reporting the fork event, was therefore resumed freely, instead
of confined to the addresses of the stepped line.  Note that since this
is a "next", it could be that we have entered a function, installed a
step-resume breakpoint, and it's ok to continue freely the stepping
thread, but that's not the case here.  The two snippets shown above were
next to each other in the logs.

For the fork case, we can resume stepping right after handling the
event.

However, for the vfork case, where we are waiting for the
external child process to exec or exit, we only resume the thread that
called vfork, and keep the others stopped (see patch "gdb: fix handling of
vfork by multi-threaded program" prior in this series).  So we can't
resume the stepping thread right now.  Instead, do it after handling the
vfork-done event.

Change-Id: I92539c970397ce880110e039fe92b87480f816bd
2022-04-04 22:11:57 -04:00

117 lines
3.9 KiB
Plaintext

# Copyright 2022 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 doing a "next" on a thread during which forks or vforks happen in other
# threads.
standard_testfile
# Line where to stop the main thread.
set break_here_line [gdb_get_line_number "break here"]
# Build executables, one for each fork flavor.
foreach_with_prefix fork_func {fork vfork} {
set opts [list debug pthreads additional_flags=-DFORK_FUNC=${fork_func}]
if { [build_executable "failed to prepare" \
${testfile}-${fork_func} ${srcfile} $opts] } {
return
}
}
# If testing against GDBserver, consume all it its output.
proc drain_gdbserver_output { } {
if { [info exists ::server_spawn_id] } {
gdb_test_multiple "" "" {
-i "$::server_spawn_id"
-timeout 0
-re ".+" {
exp_continue
}
}
}
}
# Run the test with the given parameters:
#
# - FORK_FUNC: fork flavor, "fork" or "vfork".
# - TARGET-NON-STOP: "maintenance set target-non-stop" value, "auto", "on" or
# "off".
# - NON-STOP: "set non-stop" value, "on" or "off".
# - DISPLACED-STEPPING: "set displaced-stepping" value, "auto", "on" or "off".
proc do_test { fork_func target-non-stop non-stop displaced-stepping } {
save_vars { ::GDBFLAGS } {
append ::GDBFLAGS " -ex \"maintenance set target-non-stop ${target-non-stop}\""
append ::GDBFLAGS " -ex \"set non-stop ${non-stop}\""
clean_restart ${::binfile}-${fork_func}
}
gdb_test_no_output "set displaced-stepping ${displaced-stepping}"
if { ![runto_main] } {
return
}
# The "Detached after (v)fork" messages get in the way in non-stop, disable
# them.
gdb_test_no_output "set print inferior-events off"
# Advance the next-ing thread to the point where we'll execute the nexts.
# Leave the breakpoint in: it will force GDB to step over it while next-ing,
# which exercises some additional code paths.
gdb_test "break $::break_here_line" "Breakpoint $::decimal at $::hex.*"
gdb_test "continue" "hit Breakpoint $::decimal, main.*"
# Next an arbitrary number of times over the lines of the loop.
#
# It is useful to bump this number to a larger value (e.g. 200) to stress
# test more, but it makes the test case run for considerably longer. If
# you increase the number of loops, you might want to adjust the alarm
# time in the .c file accordingly.
for { set i 0 } { $i < 20 } { incr i } {
# If testing against GDBserver, the forking threads cause a lot of
# "Detaching from process XYZ" messages to appear. If we don't consume
# that output, GDBserver eventually blocks on a full stderr. Drain it
# once every loop. It may not be needed for 20 iterations, but it's
# needed if you increase to 200 iterations.
drain_gdbserver_output
with_test_prefix "i=$i" {
if { [gdb_test "next" "other line.*" "next to other line"] != 0 } {
return
}
if { [gdb_test "next" "for loop.*" "next to for loop"] != 0 } {
return
}
if { [gdb_test "next" "break here.*" "next to break here"] != 0} {
return
}
}
}
}
foreach_with_prefix fork_func {fork vfork} {
foreach_with_prefix target-non-stop {auto on off} {
foreach_with_prefix non-stop {off on} {
foreach_with_prefix displaced-stepping {auto on off} {
do_test ${fork_func} ${target-non-stop} ${non-stop} ${displaced-stepping}
}
}
}
}