aboutsummaryrefslogtreecommitdiff
path: root/sim
diff options
context:
space:
mode:
authorSimon Marchi <simon.marchi@efficios.com>2021-12-01 09:40:03 -0500
committerSimon Marchi <simon.marchi@efficios.com>2021-12-08 21:00:39 -0500
commit577d2167bbed078e99fe8b704f936be8ac7cf83d (patch)
tree7718ef8811dfd386cc891ab2180dfecd7271386c /sim
parent28561a655942f8e2a70a3b64e867223a60aae7b1 (diff)
downloadgdb-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