From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BDKiN5RxTmd7OwIAWB0awg (envelope-from ) for ; Mon, 02 Dec 2024 21:48:52 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=default header.b=Ve51WQ/A; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D75431E0BB; Mon, 2 Dec 2024 21:48:52 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.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 autolearn=unavailable autolearn_force=no version=4.0.0 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 3D0F31E05C for ; Mon, 2 Dec 2024 21:48:52 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5B3FF3857C78 for ; Tue, 3 Dec 2024 02:48:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B3FF3857C78 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=default header.b=Ve51WQ/A Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 28E363858423 for ; Tue, 3 Dec 2024 02:48:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 28E363858423 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 28E363858423 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1733194096; cv=none; b=vyvjfhuZjAGsVxxHKvWSEKqedx0dWP0izshYWJEoj6vy5yXWKuD6AOzEyWsFxBp+YL+jQ0/o4iHho0kkpVsXR0AcmdgH2Jmeou4kxb2v+f23fYTwxrXgZi4UZyPFvX3p8cvBbgP7rjzEpK7fqgrslB+yVcT1R/Nhjtf8vOi/fDg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1733194096; c=relaxed/simple; bh=Jam1eIGV1c52fFuBfBMHFEyecoSM7JrgDExpciS3OMs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=UBwy6q+rWqqDWfkSMEMNeSkCxdy+pd4n8AI6qiNqajKJc1tiD7h5Mtuqp8Xky9OLot554K5JVqf5VGcy4ijbtTCzWJiNyo7X9o/CWVQs/28CW8weQqpO4soSTJid+g07TPU+l6MuqWTH6LD+UmYS5GgXef1WXHh0gEZVdCYFwgY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 28E363858423 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 4B32mAFu052193 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 2 Dec 2024 21:48:15 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 4B32mAFu052193 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1733194095; bh=66ikX+LZKGTkDPd0odEVOTjgg7zxaw3iMt4Glh6UXXw=; h=Date:Subject:To:From:In-Reply-To:From; b=Ve51WQ/AcAP4Kavw+JYO9Okz/Wcd7pEg/ZcGd9LeJ8zjSUd0aO0YNnGYWWyS2/kGz zJRCIQ+Pqj/NzfSz8GTImnGFZIIk1boJRYKVS8zD7UbHyU7QOGlDq7zXfL4aai/TkT Lrwy560FurbOxxN0G+xVVkzhFa7K5H6VFbtToUm0= Received: by simark.ca (Postfix, from userid 112) id C41461E0C0; Mon, 2 Dec 2024 21:48:10 -0500 (EST) Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id B76941E05C; Mon, 2 Dec 2024 21:48:09 -0500 (EST) Message-ID: Date: Mon, 2 Dec 2024 21:48:09 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdbserver/win32-low.cc: remove use of `all_threads` To: "Rohr, Stephan" , "gdb-patches@sourceware.org" References: <20241202194722.1297596-1-simon.marchi@polymtl.ca> Content-Language: en-US From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 3 Dec 2024 02:48:10 +0000 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 2024-12-02 15:48, Rohr, Stephan wrote: > Hi Simon, > > thanks for fixing this. I missed to check the windows build when submitting the > thread map patch for GDBserver. The fix itself looks ok, but I also cannot judge if > GDBserver only supports a single process at a time. We could also use something > like > > int num_threads = 0; > for_each_process ([&num_threads] (process_info *process) > { > num_threads += process->thread_map ().size (); > }); > > if (num_threads == 0) > return; > > to preserve the same behaviour as implemented now. Even though it looks like preserving the same behaviour in surface, I don't think it makes sense. Let's saywe did the work to make GDBserver for Windows multi-process, what would this check become? My intuition is that this would be changed to check the number of threads in the process the thread being deleted belongs to, not the overall number of threads. So adding that loop wouldn't go in the right direction. I don't know the exact reason for this check to exist in the first place, my guess is that we must always have at least one thread in the process for things not to explode, and if this is indeed the last thread existing, then an "exit process" event will likely follow. However, the patch could probably be improved by not using `current_process ()`. The caller of this function, `get_child_debug_event ()`, would likely not have set the current process to the right one. So it would perhaps be better to write the function like this instead: static void child_delete_thread (DWORD pid, DWORD tid) { thread_info *thread = find_thread_ptid (ptid_t (pid, tid)); if (thread == NULL) return; /* If the last thread is exiting, just return. */ if (thread->process ()->thread_map ().size () == 1) return; delete_thread_info (thread); } Would that make sense? Simon