aboutsummaryrefslogtreecommitdiff
path: root/gdb/arch-utils.c
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@polymtl.ca>2021-08-05 12:21:35 -0400
committerSimon Marchi <simon.marchi@polymtl.ca>2021-08-10 15:51:56 -0400
commit69eadcc9eacf8d4a99ecfcb29c9fbb4eb398b9d8 (patch)
treedd3d3a4e13eb3430473b106249c068307da288de /gdb/arch-utils.c
parent3ee0cd9e55368d162aea19a42369f3ee2a1356f3 (diff)
downloadbinutils-69eadcc9eacf8d4a99ecfcb29c9fbb4eb398b9d8.zip
binutils-69eadcc9eacf8d4a99ecfcb29c9fbb4eb398b9d8.tar.gz
binutils-69eadcc9eacf8d4a99ecfcb29c9fbb4eb398b9d8.tar.bz2
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
Diffstat (limited to 'gdb/arch-utils.c')
0 files changed, 0 insertions, 0 deletions