From: Pedro Alves <pedro@palves.net>
To: Simon Marchi <simon.marchi@polymtl.ca>, gdb-patches@sourceware.org
Cc: Simon Marchi <simon.marchi@efficios.com>
Subject: Re: [PATCH v3 6/7] gdb: move clearing of tp->pending_follow to follow_fork_inferior
Date: Fri, 3 Dec 2021 23:43:48 +0000 [thread overview]
Message-ID: <fd672f50-9add-b380-94ca-14f84fbd9bd5@palves.net> (raw)
In-Reply-To: <20211201144500.627736-7-simon.marchi@polymtl.ca>
On 2021-12-01 14:44, Simon Marchi via Gdb-patches wrote:
> From: Simon Marchi <simon.marchi@efficios.com>
>
> 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.
>
OK.
next prev parent reply other threads:[~2021-12-03 23:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 14:44 [PATCH v3 0/7] Fix handling of pending fork events Simon Marchi
2021-12-01 14:44 ` [PATCH v3 1/7] gdbserver: hide fork child threads from GDB Simon Marchi
2021-12-03 23:30 ` Pedro Alves
2021-12-01 14:44 ` [PATCH v3 2/7] gdb/linux-nat: factor ptrace-detach code to new detach_one_pid function Simon Marchi
2021-12-03 23:30 ` Pedro Alves
2021-12-01 14:44 ` [PATCH v3 3/7] gdbserver: suppress "Detaching from process" message Simon Marchi
2021-12-03 23:42 ` Pedro Alves
2021-12-04 2:57 ` Simon Marchi
2021-12-01 14:44 ` [PATCH v3 4/7] gdb/remote.c: move some things up Simon Marchi
2021-12-03 23:42 ` Pedro Alves
2021-12-01 14:44 ` [PATCH v3 5/7] gdb/remote.c: refactor pending fork status functions Simon Marchi
2021-12-03 23:43 ` Pedro Alves
2021-12-04 3:03 ` Simon Marchi
2021-12-01 14:44 ` [PATCH v3 6/7] gdb: move clearing of tp->pending_follow to follow_fork_inferior Simon Marchi
2021-12-03 23:43 ` Pedro Alves [this message]
2021-12-01 14:45 ` [PATCH v3 7/7] gdb, gdbserver: detach fork child when detaching from fork parent Simon Marchi
2021-12-03 23:44 ` Pedro Alves
2021-12-04 3:36 ` Simon Marchi
2021-12-07 23:25 ` Pedro Alves
2021-12-08 19:54 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fd672f50-9add-b380-94ca-14f84fbd9bd5@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--cc=simon.marchi@efficios.com \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).