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.129.124]) by sourceware.org (Postfix) with ESMTPS id A9A023858C54 for ; Wed, 7 Jun 2023 17:52:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9A023858C54 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=1686160376; 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=UrNzFvzAtZBVAgpJifmfgxXAmM5DHh4YiGc0fu4Kepo=; b=MSVuLjvvKifjLNLo91g0YNOORAVqPRL6lRKSTD3Hv0JvVNeqrfmqoCarGYnahQvLEcjc8B /UA2i0NJYsWHSme9+tAtpHtSfi8SlYn350EyeyGzLRYq7fe6nbajjj13c2gAtwsdK2E384 fh2BorHg6YVzXCFTlZ6Ayz05Bo71jEk= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-217-1xdaqLoXM5-CKx3Bu2Wcmg-1; Wed, 07 Jun 2023 13:52:54 -0400 X-MC-Unique: 1xdaqLoXM5-CKx3Bu2Wcmg-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-3f7f4dc6ec2so2949125e9.0 for ; Wed, 07 Jun 2023 10:52:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686160372; x=1688752372; 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=UrNzFvzAtZBVAgpJifmfgxXAmM5DHh4YiGc0fu4Kepo=; b=BO7mxeEN+vJb5GK471dtwPye9HTweXTFy32u8Whb+5ew12+UYaCP8DWqI3QI94YMKL LerHUoRLvgIHeR1Z2AW7nxwAZ1ot8jVD3F8FUBYdWJ8X3P4WAH4lN1Q634ca1fDyP5Xy cNuouUQhn821d7X0kse6Tp4sNVdK8xpnkpBgRhgRb3cL5lSqh38wGELeIqOrPruzsp6g b5MBXWU+0Ol16OHt7VDl/yRkEHRrskGi48OrN0049hbFzZ3ELgFhgLGQgOTdE1TRsPcF AdyFT79mwFI7j1DQY2es3clTlDoZqOjOL1IKiC98gtxbL8p/2rZ6G1/L/mwV0j6nrJ2b bboQ== X-Gm-Message-State: AC+VfDwK48Myfa6/roRHuxq5kKmNvh4n2YuhhevEBgK2oFjFVNRzGv7f 2j6DPAn8p8mdEcI0WowbBIvkDZWiCXXMH0YumlhZ3VCTTNTztg96l3iVdOL/q5CQoUjbO/KQC8y k10BffmEnbl3t8QbMLkwOUS4tQbtzTQ== X-Received: by 2002:adf:e8c7:0:b0:309:5119:7259 with SMTP id k7-20020adfe8c7000000b0030951197259mr5144867wrn.20.1686160372368; Wed, 07 Jun 2023 10:52:52 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ51jh2c1CIMB6nLJFUJu1FW3BS5aBpcCvw14BGv6b3CRxwmY70cg8JMtILZwR2W4Pbl0mY59A== X-Received: by 2002:adf:e8c7:0:b0:309:5119:7259 with SMTP id k7-20020adfe8c7000000b0030951197259mr5144861wrn.20.1686160372086; Wed, 07 Jun 2023 10:52:52 -0700 (PDT) Received: from localhost (11.72.115.87.dyn.plus.net. [87.115.72.11]) by smtp.gmail.com with ESMTPSA id s5-20020a5d4245000000b0030903d44dbcsm16065528wrr.33.2023.06.07.10.52.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jun 2023 10:52:51 -0700 (PDT) From: Andrew Burgess To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH 14/31] all-stop/synchronous RSP support thread-exit events In-Reply-To: <20221212203101.1034916-15-pedro@palves.net> References: <20221212203101.1034916-1-pedro@palves.net> <20221212203101.1034916-15-pedro@palves.net> Date: Wed, 07 Jun 2023 18:52:50 +0100 Message-ID: <87zg5byxal.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.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: > Currently, GDB does not understand the THREAD_EXITED stop reply in > remote all-stop mode. There's no good reason for this, it just > happened that THREAD_EXITED was only ever reported in non-stop mode so > far. This patch teaches GDB to parse that event in all-stop RSP too. > There is no need to add a qSupported feature for this, because the > server won't send a THREAD_EXITED event unless GDB explicitly asks for > it, with QThreadEvents, or with the GDB_THREAD_OPTION_EXIT > QThreadOptions option added in the next patch. > > Change-Id: Ide5d12391adf432779fe4c79526801c4a5630966 > --- > gdb/remote.c | 5 +++-- > gdbserver/server.cc | 1 + > 2 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/gdb/remote.c b/gdb/remote.c > index 9de8ed8a068..f7ab8523fd5 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -8172,7 +8172,8 @@ remote_target::process_stop_reply (struct stop_reply *stop_reply, > && status->kind () != TARGET_WAITKIND_NO_RESUMED) > { > /* Expedited registers. */ > - if (!stop_reply->regcache.empty ()) > + if (status->kind () != TARGET_WAITKIND_THREAD_EXITED > + && !stop_reply->regcache.empty ()) I haven't investigated if this crops up, but, inside the if block we call xfree to release some of the regcache data. If it was ever the case the status->kind() was THREAD_EXITED, and the regcache was not empty, would we then leak memory? If THREAD_EXITED implies that the regcache is empty could we use an assert here instead of adding the kind check to the if? Maybe: if (!stop_reply->regcache.empty ()) { gdb_assert (status->kind () != TARGET_WAITKIND_THREAD_EXITED); ... But maybe that's bad because we'd be making assert based on state that arrives from gdbserver. In which case, should we perform some action to ensure that the regcache data is correctly freed? Thanks, Andrew > { > struct regcache *regcache > = get_thread_arch_regcache (this, ptid, stop_reply->arch); > @@ -8358,7 +8359,7 @@ remote_target::wait_as (ptid_t ptid, target_waitstatus *status, > again. Keep waiting for events. */ > rs->waiting_for_stop_reply = 1; > break; > - case 'N': case 'T': case 'S': case 'X': case 'W': > + case 'N': case 'T': case 'S': case 'X': case 'W': case 'w': > { > /* There is a stop reply to handle. */ > rs->waiting_for_stop_reply = 0; > diff --git a/gdbserver/server.cc b/gdbserver/server.cc > index 07a3319d114..5099db1ee31 100644 > --- a/gdbserver/server.cc > +++ b/gdbserver/server.cc > @@ -3061,6 +3061,7 @@ resume (struct thread_resume *actions, size_t num_actions) > > if (cs.last_status.kind () != TARGET_WAITKIND_EXITED > && cs.last_status.kind () != TARGET_WAITKIND_SIGNALLED > + && cs.last_status.kind () != TARGET_WAITKIND_THREAD_EXITED > && cs.last_status.kind () != TARGET_WAITKIND_NO_RESUMED) > current_thread->last_status = cs.last_status; > > -- > 2.36.0