From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 1551) id 9F6A03858039; Thu, 10 Mar 2022 11:42:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9F6A03858039 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable From: Pedro Alves To: gdb-cvs@sourceware.org Subject: [binutils-gdb] gdbserver: Reindent check_zombie_leaders X-Act-Checkin: binutils-gdb X-Git-Author: Pedro Alves X-Git-Refname: refs/heads/master X-Git-Oldrev: 5406bc3f1b3a8b9a653b80bae25253b1841adb46 X-Git-Newrev: aa40a989efdf2ab3960f4ed4ac44d89cef8a9ef3 Message-Id: <20220310114207.9F6A03858039@sourceware.org> Date: Thu, 10 Mar 2022 11:42:07 +0000 (GMT) X-BeenThere: gdb-cvs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-cvs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2022 11:42:07 -0000 https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3Daa40a989efdf= 2ab3960f4ed4ac44d89cef8a9ef3 commit aa40a989efdf2ab3960f4ed4ac44d89cef8a9ef3 Author: Pedro Alves Date: Thu Feb 24 11:35:43 2022 +0000 gdbserver: Reindent check_zombie_leaders =20 This fixes the indentation of linux_process_target::check_zombie_leaders, which will help with keeping its comments in sync with the gdb/linux-nat.c counterpart. =20 Change-Id: I37332343bd80423d934249e3de2d04feefad1891 Diff: --- gdbserver/linux-low.cc | 101 ++++++++++++++++++++++++---------------------= ---- 1 file changed, 50 insertions(+), 51 deletions(-) diff --git a/gdbserver/linux-low.cc b/gdbserver/linux-low.cc index f7731864c1b..442b7d9b81b 100644 --- a/gdbserver/linux-low.cc +++ b/gdbserver/linux-low.cc @@ -1721,57 +1721,56 @@ iterate_over_lwps (ptid_t filter, void linux_process_target::check_zombie_leaders () { - for_each_process ([this] (process_info *proc) { - pid_t leader_pid =3D pid_of (proc); - struct lwp_info *leader_lp; - - leader_lp =3D find_lwp_pid (ptid_t (leader_pid)); - - threads_debug_printf ("leader_pid=3D%d, leader_lp!=3DNULL=3D%d, " - "num_lwps=3D%d, zombie=3D%d", - leader_pid, leader_lp!=3D NULL, num_lwps (leader_pid), - linux_proc_pid_is_zombie (leader_pid)); - - if (leader_lp !=3D NULL && !leader_lp->stopped - /* Check if there are other threads in the group, as we may - have raced with the inferior simply exiting. */ - && !last_thread_of_process_p (leader_pid) - && linux_proc_pid_is_zombie (leader_pid)) - { - /* A leader zombie can mean one of two things: - - - It exited, and there's an exit status pending - available, or only the leader exited (not the whole - program). In the latter case, we can't waitpid the - leader's exit status until all other threads are gone. - - - There are 3 or more threads in the group, and a thread - other than the leader exec'd. On an exec, the Linux - kernel destroys all other threads (except the execing - one) in the thread group, and resets the execing thread's - tid to the tgid. No exit notification is sent for the - execing thread -- from the ptracer's perspective, it - appears as though the execing thread just vanishes. - Until we reap all other threads except the leader and the - execing thread, the leader will be zombie, and the - execing thread will be in `D (disc sleep)'. As soon as - all other threads are reaped, the execing thread changes - it's tid to the tgid, and the previous (zombie) leader - vanishes, giving place to the "new" leader. We could try - distinguishing the exit and exec cases, by waiting once - more, and seeing if something comes out, but it doesn't - sound useful. The previous leader _does_ go away, and - we'll re-add the new one once we see the exec event - (which is just the same as what would happen if the - previous leader did exit voluntarily before some other - thread execs). */ - - threads_debug_printf ("Thread group leader %d zombie " - "(it exited, or another thread execd).", - leader_pid); - - delete_lwp (leader_lp); - } + for_each_process ([this] (process_info *proc) + { + pid_t leader_pid =3D pid_of (proc); + lwp_info *leader_lp =3D find_lwp_pid (ptid_t (leader_pid)); + + threads_debug_printf ("leader_pid=3D%d, leader_lp!=3DNULL=3D%d, " + "num_lwps=3D%d, zombie=3D%d", + leader_pid, leader_lp!=3D NULL, num_lwps (leader_pid), + linux_proc_pid_is_zombie (leader_pid)); + + if (leader_lp !=3D NULL && !leader_lp->stopped + /* Check if there are other threads in the group, as we may + have raced with the inferior simply exiting. */ + && !last_thread_of_process_p (leader_pid) + && linux_proc_pid_is_zombie (leader_pid)) + { + /* A leader zombie can mean one of two things: + + - It exited, and there's an exit status pending + available, or only the leader exited (not the whole + program). In the latter case, we can't waitpid the + leader's exit status until all other threads are gone. + + - There are 3 or more threads in the group, and a thread + other than the leader exec'd. On an exec, the Linux + kernel destroys all other threads (except the execing + one) in the thread group, and resets the execing thread's + tid to the tgid. No exit notification is sent for the + execing thread -- from the ptracer's perspective, it + appears as though the execing thread just vanishes. + Until we reap all other threads except the leader and the + execing thread, the leader will be zombie, and the + execing thread will be in `D (disc sleep)'. As soon as + all other threads are reaped, the execing thread changes + it's tid to the tgid, and the previous (zombie) leader + vanishes, giving place to the "new" leader. We could try + distinguishing the exit and exec cases, by waiting once + more, and seeing if something comes out, but it doesn't + sound useful. The previous leader _does_ go away, and + we'll re-add the new one once we see the exec event + (which is just the same as what would happen if the + previous leader did exit voluntarily before some other + thread execs). */ + + threads_debug_printf ("Thread group leader %d zombie " + "(it exited, or another thread execd).", + leader_pid); + + delete_lwp (leader_lp); + } }); }