From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +OcyGZJjnmgypAMAWB0awg (envelope-from ) for ; Thu, 14 Aug 2025 18:30:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1755210642; bh=CT3pTCLNBDvT1Qs71v21anLUZFk7fDOKDpWgFzCVl0Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=OKtTtPbO07PBYehE20Zvo2d66MASujY9GGE9ohTclTond9B4vwGBRlnGuWmGJAngL nG5ODE0J8R/LfMAdLa9gIW2rZLlmdJVTWG0DZQrr8x0WSStvURX0K9FWvZO+9uL8K4 9lTxws/Wah9MK5jDL2i/+5xhuG/LXeJJHvoZ2LUc= Received: by simark.ca (Postfix, from userid 112) id 530381E08D; Thu, 14 Aug 2025 18:30:42 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=f0pZ6Hqz; dkim-atps=neutral Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C80461E08D for ; Thu, 14 Aug 2025 18:30:38 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4BE903858D20 for ; Thu, 14 Aug 2025 22:30:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4BE903858D20 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=f0pZ6Hqz Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 082D33858C2A for ; Thu, 14 Aug 2025 22:28:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 082D33858C2A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 082D33858C2A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1755210494; cv=none; b=C3q3IPs6M8VthlVrDwVH+Yw1RQcQv04yFrSCmRRZZ5OR4w23ypOCaPgOFyLLvkcBWmC+msrEIne/KFO5ilLNnkyeS/phqTv13BeKbelRoVOSD8e1u3m2JPwByMScgkGLYZyaTzLXrfLP4kAZgS/3yH189OH+hz2fCvPbq9PFnSM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1755210494; c=relaxed/simple; bh=CT3pTCLNBDvT1Qs71v21anLUZFk7fDOKDpWgFzCVl0Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ltgKJVGBagIhKxplnMxK7cjHOaUG8ALz1R5WfqyhOXkwyb9IsPn026v4/iJmkC2syD3vPCdyb4o4EQkaxBmuQdeK9y6e2cDn14KRyppR2kkCWGm/HjMpYoAAfjTZ2sDHgG/Fj/oV+Rhg2iz8Pu1+3anTPQueeUossw3sCNLXVAM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1755210493; bh=CT3pTCLNBDvT1Qs71v21anLUZFk7fDOKDpWgFzCVl0Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=f0pZ6Hqz1qWNT8sjNk7tny/7sQkmyVi3alasA1EQK2CN8FKzVJP549MSU9HFUDZGJ XT+O4yqz503WikHYqOnT4aJFzoEpZcGJHJy8nCt2DncQxcMJZN1QfSxCwPHDyPD4bz skKshoDpU5nQsoe83bYcNgTPK+wYH/ija2ujh2cg= Received: by simark.ca (Postfix) id 634B71E08D; Thu, 14 Aug 2025 18:28:13 -0400 (EDT) Message-ID: Date: Thu, 14 Aug 2025 18:28:12 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] gdb, remote: fix set_thread () in start_remote () To: Thiago Jung Bauermann , Markus Metzger Cc: gdb-patches@sourceware.org References: <20250805071914.3832823-1-markus.t.metzger@intel.com> <20250805071914.3832823-2-markus.t.metzger@intel.com> <87cy8yzfu4.fsf@linaro.org> Content-Language: fr From: Simon Marchi In-Reply-To: <87cy8yzfu4.fsf@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 8/14/25 12:29 AM, Thiago Jung Bauermann wrote: > Markus Metzger writes: >> diff --git a/gdb/remote.c b/gdb/remote.c >> index 6208a90f94a..9b76578bd80 100644 >> --- a/gdb/remote.c >> +++ b/gdb/remote.c >> @@ -5293,7 +5293,7 @@ remote_target::start_remote_1 (int from_tty, int extended_p) >> target_update_thread_list (); >> >> /* Let the stub know that we want it to return the thread. */ > > This comment is a bit cryptic. What about something like: > > /* Let the stub know that we want it to return the thread id in the > qC reply from the get_current_thread call below. */ > >> - set_continue_thread (minus_one_ptid); >> + set_general_thread (any_thread_ptid); >> >> if (thread_count (this) == 0) >> { > > Also, your explanation implies that the doc comment in > remote_target::set_thread isn't quite right. What about changing it to > something along the following lines? > > -/* If PTID is MAGIC_NULL_PTID, don't set any thread. If PTID is > - MINUS_ONE_PTID, set the thread to -1, so the stub returns the > - thread. If GEN is set, set the general thread, if not, then set > - the step/continue thread. */ > +/* If PTID is MAGIC_NULL_PTID or ANY_THREAD_PTID, set the thread to 0. > + If PTID is MINUS_ONE_PTID, set the thread to -1. If GEN is set, set > + the general thread, if not, then set the step/continue thread. If > + the thread is 0 or -1 and GEN is set, the stub returns the thread in > + the qC packet reply. */ The parts "set the thread to 0" and "set the thread to -1" seem not very useful to me. What does that mean concretely? It would be more useful to explain what that instruct the remote target to do. My understanding is that passing either MAGIC_NULL_PTID or ANY_THREAD_PTID will result in sending `Hg0` or `Hc0`. Passing MINUS_ONE_PTID will result in sending `Hg-1` or `Hc-1`. On the other side, all of these will result in variable THREAD_ID being set to null_ptid. For Hg, we'll arbitrarily pick the first thread. For Hc, we'll set cs.cont_thread to null_ptid. Does that sound right? > void > remote_target::set_thread (ptid_t ptid, int gen) > { > @@ -3267,6 +3268,7 @@ remote_target::set_thread (ptid_t ptid, int gen) > > *buf++ = 'H'; > *buf++ = gen ? 'g' : 'c'; > + /* NB: gdbserver interprets 0 and -1 the same way in the H packet. */ > if (ptid == magic_null_ptid) > xsnprintf (buf, endbuf - buf, "0"); > else if (ptid == any_thread_ptid) > > One final comment: I agree with your conclusions, but unfortunately I'm > not sure of them. The doc comment in remote_target::set_thread gives me > a bit of pause. Because of that I don't think I should add a > Reviewed-by. > > Hopefully someone with more experience with the RSP and remote stubs can > weigh in. Markus, could you elaborate on how this bug was a problem for you, what consequences it has down the line? The change seems right, but I also need some help convincing myself that it is indeed right. It seems to me like any "recent" gdbserver will send back a stop reply on connection, so remote_target::get_current_thread will not send a qC to return the current thread. Simon