From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rTPmGvjY/GnAuh8AWB0awg (envelope-from ) for ; Thu, 07 May 2026 14:24:56 -0400 Received: by simark.ca (Postfix, from userid 112) id 5D9671E0BA; Thu, 07 May 2026 14:24:56 -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.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 B73FF1E067 for ; Thu, 07 May 2026 14:24:55 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3D69C4BA798A for ; Thu, 7 May 2026 18:24:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3D69C4BA798A Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by sourceware.org (Postfix) with ESMTPS id 941274BA23FF for ; Thu, 7 May 2026 18:24:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 941274BA23FF Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 941274BA23FF Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778178270; cv=none; b=Y8wLKZJpe88qBcifWsXePxX4rrPzXEofqRyz+fk0Ni2wj9xA0aTQogc3OTJQ6/U1kGeY7Rcqi5Imwmwsm4A6Y1US1bNN9c84fnGtfmpUcxREVE2jNbPgDUODrsynP1oQi9C4hstHHIRd4EzVja7gNyvhm1i9Lhp2mG8wFDWHL58= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778178270; c=relaxed/simple; bh=FJC1/Q+8KuL3pbu0SqOgTVQos5wnNG8VM7bvxF31X1E=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=BdV8vA6mO+m9s18ez43egMo58LxqBjFuPwKpu/QEcL8Zo0DWRZCmppGCrAcpAXR5+9kYtRToytShGGm8PYZOaBZDw/sZpH/0CjUHzqD3qCTbEzk36jV6KP9h188gAWCr5riaVGG9K2/697ZCNYztiP5hzYAgtTvOyhpLp9IlFZM= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 941274BA23FF Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4891d7164ddso7779335e9.3 for ; Thu, 07 May 2026 11:24:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778178269; x=1778783069; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=JHjfVU9mhkR2zMX5uJHjUMp2C0u+cXrRYqDFjeJiqGc=; b=mtYGAk6hC7SHdYi+rxL3UpTErZyvspkQnNlpgkQz5O3gVmL1SLqOqJD/29vmGATK8K 29w3MX1OzNy0AI0UEEUfeJNdRDhMJinioTjIbYjwPA5/pE/P5L3/XNJfHVzMFBY/rRrf n4nLSQEJhKA/xP6rzc32o4w6loAjxoel9J8Er5XdYruZxWmWuZGj2fDOXS5B/F0512Pv 8xXYlnGwQyVreiBbA91S2g0oWH5wwholb3oHG9JxDduVYlS4Pw4Y1P5uGIqmginzJWf1 okQhuH8ddQwjzpkmKR0NQg6jiK6c/nXvYah7mGxUz8lygHUmOLNuLH91riqNS/6jIde9 +Byg== X-Gm-Message-State: AOJu0YxqjKW7Q/DvQnhHvWJDBLwNyLrEIIXRW6zqL3sFyj6TGm8HiD3a VCVvdlo0ajfmC3ijpuiGeZlqBsY+HALq37P2c41Ic/9f1y7dJoxvmNTKmmsMdA== X-Gm-Gg: AeBDievgVZNt3Xx2lPDYmBPXgr8ws5SeNMN4LzU8ve/ej7MUbGrc2fbl8Dlg1X7CwZN BLOyPMfuFGD53mdVajDkCffISEckZo4MKxCQb6qUsBpbv3VQTFqiqqsHwg6eubXWIFfEPjCp/7U 64nvAkbgx39OzJ2C1g9/SADSLkgv2d6kW+p13967e+fOq5ZBULFfIv19gVfzOmKUcjh2peJWBmB trKb0adXmaSnPoRildSBYLihjYgpA7myTy3BG47N+0PJa7eqoqS1YoDxI8a8uL6X6a4ZVtHwsK/ GLvvwmlSH102ksyAv899J8Y1vFZknoRTtI+mI1OkpB9AOh3fXv/rTRVPU3+e0ZdPqWkihi5DzLA IdtnUJUr7+Xf+6FcoFuNVoMl6wxH23Nmoh1MQ8DnqmbZLCS+uh2owKOjOekHeKmdulzHT4FL3LA CaqLr12LqEU64VzG5i+zNggu2p4gamI8/hhD2HnOAbin6HDLRFL9maRb0GsWARHxo= X-Received: by 2002:a05:600c:8485:b0:48d:5c1:bc47 with SMTP id 5b1f17b1804b1-48e51f32a6fmr155484885e9.15.1778178269226; Thu, 07 May 2026 11:24:29 -0700 (PDT) Received: from ?IPV6:2001:8a0:facb:a800:4a00:4ee0:fe55:363? ([2001:8a0:facb:a800:4a00:4ee0:fe55:363]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e538d2878sm225903435e9.15.2026.05.07.11.24.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2026 11:24:28 -0700 (PDT) Message-ID: <57bee2c4-4cde-40aa-a08e-137a97f471d4@palves.net> Date: Thu, 7 May 2026 19:24:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Windows gdb: Avoid hang second attach/run To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20260505121823.1442331-1-pedro@palves.net> <87o6iueytu.fsf@tromey.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <87o6iueytu.fsf@tromey.com> 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 2026-05-05 15:05, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> windows_nat_target::attach and windows_nat_target::create_inferior > Pedro> both hang in this situation, because they call into do_synchronously, > Pedro> which hangs because the 'process_thread' thread is blocked in > Pedro> WaitForDebugEvent. > > Do we need something similar for gdbserver? We don't, because gdbserver does not have the do_synchronously machinery for async, and, also, because core gdbserver rejects the attach earlier: if (startswith (own_buf, "vAttach;")) { if ((!extended_protocol || !cs.multi_process) && target_running ()) { fprintf (stderr, "Already debugging a process\n"); write_enn (own_buf); return; } We get: attach 22600 Attaching to Remote target Attaching to Remote target failed: 01 (gdb) FAIL: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again BTW, I'm been thinking that the slow piecemeal sharing of code between gdb and gdbserver's Windows backends is a lost cause by now. The backends started diverging a lot with the async support, and more so now with the non-stop support. They used to be very similar before. I've been thinking that it'll be easier to completely dump gdbserver/win32-low.c, make gdbserver build gdb/windows-nat.c (and friends), start with some #ifdefs, and then work on eliminating the #ifdefs incrementally with some abstractions and/or normalizing gdb and gdbserver core<=>backend interfaces more. > > Pedro> Until the Windows backend is taught to debug multiple processes, which > Pedro> will probably require having one process_thread thread per inferior, > Pedro> detect the situation and error out before GDB hangs. > > Yeah. I've never understood why MS did things this way instead of the > seemingly obvious approach of having debug events integrated into > WaitForMultipleObjects. > > Pedro> There are still other failures not addressed by this patch. > > FWIW the internal AdaCore automated testing shows a number of failures > after a merge on 20260427. I guess when I did my testing I happened to > pick the one particular OS instance that had no problems :( Ouch, I was indeed surprised that you saw no problems. :-/ (To be clear, the failures I mean above are pre-existing failures in gdb.base/attach.exp.) Pedro Alves