From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 020783858D35 for ; Thu, 16 Mar 2023 16:19:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 020783858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678983586; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XkyW3xAbrFzAQvl/iLLAhWE7+nmjdGY89LPWYASnO38=; b=YKsTniT+4m3mWDtkep38snTCAUAkW5K9V1rW6sOjp4DCnlYShFYTp6ysQGzOYMw8tm0dUA bYV2JVmZH4HL2naewiOkky/hV4JMg1p0L8j2ivUPO0HXQfYDfz0ZU8vzsl7DE+ruZ62wIM x673N9b1V8pHSeqUnO9/ym7FWnK1TLw= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-554-Hr12KFp5MK-JBjZ-9FvTNA-1; Thu, 16 Mar 2023 12:19:45 -0400 X-MC-Unique: Hr12KFp5MK-JBjZ-9FvTNA-1 Received: by mail-ed1-f71.google.com with SMTP id t14-20020a056402240e00b004fb36e6d670so3783402eda.5 for ; Thu, 16 Mar 2023 09:19:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678983583; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5QTSWIKud7CdMSrh69bVqR4nHT+KC3BzRO54BQj/f2s=; b=qeI395m6+UA1vbs4xy/q83CILynf4n7NGxJojx2P5ELsHj2sXI2Tx2EWEYeOqj8ZPj ErM2jS2nR6NkfLD7wsvzso8aVt3FPq0qO/op/0mtbqTcf9tIXpKAjWabiSgq9ak6+cB6 b4h4qxWWjbjDjnPZwjXixqcA5AoD0HFUrANy/gdJ0vL9AnwpjWx8A+Lq9LX50ZMVowtJ fxsdVrjNZ7n/64bAKLTJHDlzNjfqdhC3X3968iwNxOTMu0UiG6hmtZawYnIJb2SGVt26 oDi1ps2E1KFR4IEzaMU6tmB5UXgX94d5geCCJW+XxL7Y8p6jf1l4j92rk/U91dPOVP+t dXzA== X-Gm-Message-State: AO0yUKVQJQN8J+Wcn00DVnqvn2SEzT+qLeZrbk2oTRonugIG8ooSepz6 8ZA3t9SMkAAwoHXwRY6+uPLQdnJjSnuWFs2nYnAXyx1888coiUAhcE/D4FYsivJkEF4+mrzjdm4 c77yaaYv20Zy7Nf+ElCFhaY96JMxCzg== X-Received: by 2002:a17:907:9494:b0:92e:efa:b9b4 with SMTP id dm20-20020a170907949400b0092e0efab9b4mr13427262ejc.22.1678983583681; Thu, 16 Mar 2023 09:19:43 -0700 (PDT) X-Google-Smtp-Source: AK7set/0jjKQaIHp/w0NMx4kC2v0zW+1LPPeCeRhd8IMl01Qpo8VDrDqI+g1MUBE+2e/9OSe00+Q0g== X-Received: by 2002:a17:907:9494:b0:92e:efa:b9b4 with SMTP id dm20-20020a170907949400b0092e0efab9b4mr13427237ejc.22.1678983583388; Thu, 16 Mar 2023 09:19:43 -0700 (PDT) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id m10-20020a170906848a00b008def483cf79sm3988582ejx.168.2023.03.16.09.19.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Mar 2023 09:19:42 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH 02/31] linux-nat: introduce pending_status_str In-Reply-To: References: <20221212203101.1034916-1-pedro@palves.net> <20221212203101.1034916-3-pedro@palves.net> <87cz6rrma6.fsf@redhat.com> Date: Thu, 16 Mar 2023 16:19:41 +0000 Message-ID: <87wn3gekiq.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00,DKIM_INVALID,DKIM_SIGNED,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Pedro Alves writes: > On 2023-02-03 12:00 p.m., Andrew Burgess wrote: >> Pedro Alves writes: >> >>> I noticed that some debug log output printing an lwp's pending status >>> wasn't considering lp->waitstatus. This fixes it, by introducing a >>> new pending_status_str function. >> >> This patch looks fine. I had one slightly related question: I took a >> look at the comment on lwp_info::waitstatus in linux-nat.h, which says: >> >> /* If WAITSTATUS->KIND != TARGET_WAITKIND_SPURIOUS, the waitstatus >> for this LWP's last event. This may correspond to STATUS above, >> or to a local variable in lin_lwp_wait. */ >> struct target_waitstatus waitstatus; >> >> Am I right in thinking that this comment is wrong; it should say >> TARGET_WAITKIND_IGNORE, not TARGET_WAITKIND_SPURIOUS, right? > > You're right. > > I tweaked the comments in linux-nat.h in this new version. Let me know what > you think. > > From 10f88baff2e25fb87f37d1665bf283206171dd42 Mon Sep 17 00:00:00 2001 > From: Pedro Alves > Date: Fri, 12 Nov 2021 20:50:29 +0000 > Subject: [PATCH] linux-nat: introduce pending_status_str > > I noticed that some debug log output printing an lwp's pending status > wasn't considering lp->waitstatus. This fixes it, by introducing a > new pending_status_str function. > > Also fix the comment in gdb/linux-nat.h describing > lwp_info::waitstatus and details the description of lwp_info::status > while at it. > > Change-Id: I66e5c7a363d30a925b093b195d72925ce5b6b980 > --- > gdb/linux-nat.c | 19 ++++++++++++++++--- > gdb/linux-nat.h | 11 +++++++---- > 2 files changed, 23 insertions(+), 7 deletions(-) LGTM. Reviewed-By: Andrew Burgess Thanks, Andrew > > diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c > index e5391b9ce35..9d811bbf3ff 100644 > --- a/gdb/linux-nat.c > +++ b/gdb/linux-nat.c > @@ -255,6 +255,19 @@ is_leader (lwp_info *lp) > return lp->ptid.pid () == lp->ptid.lwp (); > } > > +/* Convert an LWP's pending status to a std::string. */ > + > +static std::string > +pending_status_str (lwp_info *lp) > +{ > + gdb_assert (lwp_status_pending_p (lp)); > + > + if (lp->waitstatus.kind () != TARGET_WAITKIND_IGNORE) > + return lp->waitstatus.to_string (); > + else > + return status_to_str (lp->status); > +} > + > > /* LWP accessors. */ > > @@ -1647,8 +1660,8 @@ linux_nat_target::resume (ptid_t scope_ptid, int step, enum gdb_signal signo) > this thread with a signal? */ > gdb_assert (signo == GDB_SIGNAL_0); > > - linux_nat_debug_printf ("Short circuiting for status 0x%x", > - lp->status); > + linux_nat_debug_printf ("Short circuiting for status %s", > + pending_status_str (lp).c_str ()); > > if (target_can_async_p ()) > { > @@ -3137,7 +3150,7 @@ linux_nat_wait_1 (ptid_t ptid, struct target_waitstatus *ourstatus, > if (lp != NULL) > { > linux_nat_debug_printf ("Using pending wait status %s for %s.", > - status_to_str (lp->status).c_str (), > + pending_status_str (lp).c_str (), > lp->ptid.to_string ().c_str ()); > } > > diff --git a/gdb/linux-nat.h b/gdb/linux-nat.h > index 45534c92386..770fe924427 100644 > --- a/gdb/linux-nat.h > +++ b/gdb/linux-nat.h > @@ -232,7 +232,9 @@ struct lwp_info : intrusive_list_node > /* The last resume GDB requested on this thread. */ > resume_kind last_resume_kind = resume_continue; > > - /* If non-zero, a pending wait status. */ > + /* If non-zero, a pending wait status. A pending process exit is > + recorded in WAITSTATUS, because W_EXITCODE(0,0) happens to be > + 0. */ > int status = 0; > > /* When 'stopped' is set, this is where the lwp last stopped, with > @@ -260,9 +262,10 @@ struct lwp_info : intrusive_list_node > /* Non-zero if we expect a duplicated SIGINT. */ > int ignore_sigint = 0; > > - /* If WAITSTATUS->KIND != TARGET_WAITKIND_SPURIOUS, the waitstatus > - for this LWP's last event. This may correspond to STATUS above, > - or to a local variable in lin_lwp_wait. */ > + /* If WAITSTATUS->KIND != TARGET_WAITKIND_IGNORE, the waitstatus for > + this LWP's last event. This usually corresponds to STATUS above, > + however because W_EXITCODE(0,0) happens to be 0, a process exit > + will be recorded here, while 'status == 0' is ambiguous. */ > struct target_waitstatus waitstatus; > > /* Signal whether we are in a SYSCALL_ENTRY or > > base-commit: 2562954ede66f32bff7d985e752b8052c2ae5775 > prerequisite-patch-id: bbc9918ac5f79de07a29f34ec072794d270f942d > -- > 2.36.0