gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit
authorSimon Marchi <simon.marchi@polymtl.ca>
Thu, 5 Aug 2021 16:21:35 +0000 (12:21 -0400)
committerSimon Marchi <simon.marchi@polymtl.ca>
Tue, 10 Aug 2021 19:51:56 +0000 (15:51 -0400)
commit69eadcc9eacf8d4a99ecfcb29c9fbb4eb398b9d8
treedd3d3a4e13eb3430473b106249c068307da288de
parent3ee0cd9e55368d162aea19a42369f3ee2a1356f3
gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit

I spotted what I think is a buglet in proceed_after_vfork_done.  After a
vfork child exits or execs, we resume all the threads of the parent.  To
do so, we iterate on all threads using iterate_over_threads with the
proceed_after_vfork_done callback.  Each thread is resumed if the
following condition is true:

    if (thread->ptid.pid () == pid
&& thread->state == THREAD_RUNNING
&& !thread->executing
&& !thread->stop_requested
&& thread->stop_signal () == GDB_SIGNAL_0)

where `pid` is the pid of the vfork parent.  This is not multi-target
aware: since it only filters on pid, if there is an inferior with the
same pid in another target, we could end up resuming a thread of that
other inferior.  The chances of the stars aligning for this to happen
are tiny, but still.

Fix that by iterating only on the vfork parent's threads, instead of on
all threads.  This is more efficient, as we iterate on just the required
threads (inferiors have their own thread list), and we can drop the pid
check.  The resulting code is also more straightforward in my opinion,
so it's a win-win.

Change-Id: I14647da72e2bf65592e82fbe6efb77a413a4be3a
gdb/infrun.c