From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by sourceware.org (Postfix) with ESMTPS id C9DF03857C6C for ; Thu, 3 Mar 2022 14:40:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C9DF03857C6C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f45.google.com with SMTP id j17so8249149wrc.0 for ; Thu, 03 Mar 2022 06:40:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HmGMZAhKm/0Ibx1RJox1DQFDklh2jus9SaghelIgrVA=; b=equCko0N4pMRGqT7tXl8S/kwkZz1QFHCy4dc4aqrXZMcV9S+EPMmb6eakAJTl0QHVv UZxvm0+M0U3oQXzZrZcGuxkgiauayLRrL391vRga80+OLBDc2XNO8Sx58VryuJnxOErt UW03/x0KMTpgOxiSX8TG9ZQZ/4xpx0NTeAe+1EnbOqI57WCg30o0cwiRhApcBI4NByVQ r2cJg/HJYG2vjs4zJUc/L+1Nhf+SbWlCK3yS2Api4gJp/pyW4mIleUMieMV7ENiXLP8o lvFfvQ+Csh6pYzhTk+lHSOyGzDLAEIX3F3AHgPWwhcKWzu5vSLptHuZsOcSKd5dBm/+q 9ewQ== X-Gm-Message-State: AOAM531LsX+HSAn0YOZwteyEmYquTBWigvT5rkOn/hzSwr+Rqizaq/E9 DkFgdQDXMFNcUgzlNU06nxM9K3+EQIw= X-Google-Smtp-Source: ABdhPJx+/GQIBYP7ACNOGYv2s6GEGKStZJAzNVRmk7MGi15uxr7iE12EHOuRLQupamg/ChCjlYgIdQ== X-Received: by 2002:a5d:5606:0:b0:1f0:2d8b:2ff6 with SMTP id l6-20020a5d5606000000b001f02d8b2ff6mr6038798wrv.433.1646318436064; Thu, 03 Mar 2022 06:40:36 -0800 (PST) Received: from localhost ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id e6-20020a056000120600b001ea9414f2c3sm2059420wrx.12.2022.03.03.06.40.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Mar 2022 06:40:35 -0800 (PST) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 06/11] gdbserver: Reindent check_zombie_leaders Date: Thu, 3 Mar 2022 14:40:15 +0000 Message-Id: <20220303144020.3601082-7-pedro@palves.net> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20220303144020.3601082-1-pedro@palves.net> References: <20220303144020.3601082-1-pedro@palves.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2022 14:40:39 -0000 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. Change-Id: I37332343bd80423d934249e3de2d04feefad1891 --- 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 2d14a0254c7..4635d310839 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 = pid_of (proc); - struct lwp_info *leader_lp; - - leader_lp = find_lwp_pid (ptid_t (leader_pid)); - - threads_debug_printf ("leader_pid=%d, leader_lp!=NULL=%d, " - "num_lwps=%d, zombie=%d", - leader_pid, leader_lp!= NULL, num_lwps (leader_pid), - linux_proc_pid_is_zombie (leader_pid)); - - if (leader_lp != 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 = pid_of (proc); + lwp_info *leader_lp = find_lwp_pid (ptid_t (leader_pid)); + + threads_debug_printf ("leader_pid=%d, leader_lp!=NULL=%d, " + "num_lwps=%d, zombie=%d", + leader_pid, leader_lp!= NULL, num_lwps (leader_pid), + linux_proc_pid_is_zombie (leader_pid)); + + if (leader_lp != 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); + } }); } -- 2.26.2