diff options
author | Simon Marchi <simon.marchi@efficios.com> | 2021-12-01 09:40:03 -0500 |
---|---|---|
committer | Simon Marchi <simon.marchi@efficios.com> | 2021-12-08 21:00:39 -0500 |
commit | 577d2167bbed078e99fe8b704f936be8ac7cf83d (patch) | |
tree | 7718ef8811dfd386cc891ab2180dfecd7271386c /sim | |
parent | 28561a655942f8e2a70a3b64e867223a60aae7b1 (diff) | |
download | gdb-577d2167bbed078e99fe8b704f936be8ac7cf83d.zip gdb-577d2167bbed078e99fe8b704f936be8ac7cf83d.tar.gz gdb-577d2167bbed078e99fe8b704f936be8ac7cf83d.tar.bz2 |
gdb: move clearing of tp->pending_follow to follow_fork_inferior
A following patch will change targets so that when they detach an
inferior, they also detach any pending fork children this inferior may
have. While doing this, I hit a case where we couldn't differentiate
two cases, where in one we should detach the fork detach but not in the
other.
Suppose we continue past a fork with "follow-fork-mode == child" &&
"detach-on-fork on". follow_fork_inferior calls target_detach to detach
the parent. In that case the target should not detach the fork
child, as we'll continue debugging the child. As of now, the
tp->pending_follow field of the thread who called fork still contains
the details about the fork.
Then, suppose we run to a fork catchpoint and the user types "detach".
In that case, the target should detach the fork child in addition to the
parent. In that case as well, the tp->pending_follow field contains
the details about the fork.
To allow targets to differentiate the two cases, clear
tp->pending_follow a bit earlier, when following a fork. Targets will
then see that tp->pending_follow contains TARGET_WAITKIND_SPURIOUS, and
won't detach the fork child.
As of this patch, no behavior changes are expected.
Change-Id: I537741859ed712cb531baaefc78bb934e2a28153
Diffstat (limited to 'sim')
0 files changed, 0 insertions, 0 deletions