gdb: replace inferior::waiting_for_vfork_done with inferior::thread_waiting_for_vfork...
authorSimon Marchi <simon.marchi@polymtl.ca>
Wed, 12 Jan 2022 02:40:34 +0000 (21:40 -0500)
committerSimon Marchi <simon.marchi@polymtl.ca>
Tue, 5 Apr 2022 02:11:47 +0000 (22:11 -0400)
commit6f5d514f9134452ecfe0694b9025291f5abf1080
tree48385976f539ecbaeaad5b0b86e4efc5b99ae9cb
parentad62fd45460f1c6d9129115f95c9d86bcdbd8ba7
gdb: replace inferior::waiting_for_vfork_done with inferior::thread_waiting_for_vfork_done

The inferior::waiting_for_vfork_done flag indicates that some thread in
that inferior is waiting for a vfork-done event.  Subsequent patches
will need to know which thread precisely is waiting for that event.

Replace the boolean flag (waiting_for_vfork_done) with a thread_info
pointer (thread_waiting_for_vfork_done).

I think there is a latent buglet in that waiting_for_vfork_done is
currently not reset on inferior exec or exit.  I could imagine that if a
thread in the parent process calls exec or exit while another thread of
the parent process is waiting for its vfork child to exec or exit, we
could end up with inferior::waiting_for_vfork_done without a thread
actually waiting for a vfork-done event anymore.  And since that flag is
checked in resume_1, things could misbehave there.

Since the new field points to a thread_info object, and those are
destroyed on exec or exit, it could be worse now since we could try to
access freed memory, if thread_waiting_for_vfork_done were to point to a
stale thread_info.  To avoid this, clear the field in
infrun_inferior_exit and infrun_inferior_execd.

Change-Id: I31b847278613a49ba03fc4915f74d9ceb228fdce
gdb/inferior.h
gdb/infrun.c