From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by sourceware.org (Postfix) with ESMTPS id 4394E3858D20 for ; Wed, 17 Apr 2024 17:57:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4394E3858D20 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 4394E3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.47 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713376668; cv=none; b=UVY+E+WRZO0yXXw9u1NtzLHPbisk9oh21w156AUPhmvQOo7GRu7CioVdRGr1M6Rggx1GUaCTBMO4j31tORu3KOSWRFJb0JSX6MISO1z8bNl4+fPPqs0+P/Zr1niTHwP6CK8kJW2DFdkrtbrjC+icktK3c0EwDCe4kCGDzGXE9fU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713376668; c=relaxed/simple; bh=zkdTUzBSCXIwLiRxKZt0GQO8Hy8nfjZL+pMRDqdfLh4=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=pb+I5T+pUW7ocdMT2E7rlholjW+3jn2ncy2BAs6MCDYVvI/z26/ogIb/aBOQTmW7A8ZqtzLtf9MkKOLf82o3Ezd7i1clLAMYfhfkcOcdAJCd2t1n8sVltyn/W9BcEMeATKW7IDwUsUqX6WuXe1RTESy2NfzsIf1vMs0oMhhde5Y= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-415515178ceso177425e9.0 for ; Wed, 17 Apr 2024 10:57:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713376665; x=1713981465; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JaMP2oQ2hUiw82XtSZlFyVw6u8mQberQlTHHV9b5JJM=; b=sTCZ2mgKWqY7PzaTmiv7Pmzt0j9r5AuqPA4PS3nw5PafrLRgW4G7e0Vl/bICnJE62d l90ZtC6zLIueq/kvpIZY6j4mVgpVgCuGLxbzFW/6adS2Y/J2o2WjWtAtuDHIiCDwsGEQ LfxrD00N/R0ozrYzXgf9yi6xOLQZtVJKHTwWtQi+yYOuefTUlbu2clKeSzVX4wFOrk/u sQecvz3bAG+Njy6gr3Qd/yxtxiEvzNL42a4LRAzMWjFr7e0BjM9Bu/9zqpTOXozx1b0P QgRtmO2z0OB/YthEojz+UOXtiL+3kZvJfheOn6jw1bllMhJbHj8LZRx+F15IhmRrphir uadw== X-Forwarded-Encrypted: i=1; AJvYcCUR6cfHjeOMxIg4qZTV7HRKjyCXZhI6ce9AZZTQ/p/ztGSdEGBjqkYJDiZxKyATwa/JpXZIRymZNQyggUZEnFfo7GfDifAVGkqSjA== X-Gm-Message-State: AOJu0Yxkbic3GzMpa9pMojmoVQfc+lvxLSUzThkHhj00fnsyf23tH3iC K06QYOv0py8fndSBwHbt134/nFAK2zJd+8VENhuGZEoQFk0MIsBy X-Google-Smtp-Source: AGHT+IGyKPzkaIGpgix9iOlAvEnzpXJnaqZGdYzbt1+j/C9fkbidqQ+WSSZVK2xHt0g7sM27ha8Jew== X-Received: by 2002:a05:600c:5254:b0:417:d56c:5e8a with SMTP id fc20-20020a05600c525400b00417d56c5e8amr268085wmb.18.1713376664763; Wed, 17 Apr 2024 10:57:44 -0700 (PDT) Received: from ?IPV6:2001:8a0:f93d:b900:e643:3adf:640c:b3ad? ([2001:8a0:f93d:b900:e643:3adf:640c:b3ad]) by smtp.gmail.com with ESMTPSA id j1-20020a05600c1c0100b0041895d1c7bfsm3653852wms.42.2024.04.17.10.57.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 17 Apr 2024 10:57:44 -0700 (PDT) Message-ID: <69bbd1f3-7de8-4a4e-882e-0d753ec75f42@palves.net> Date: Wed, 17 Apr 2024 18:57:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] gdb/Windows: Fix detach while running To: Tom Tromey Cc: Hannes Domani , "gdb-patches@sourceware.org" References: <20240411200356.270360-1-pedro@palves.net> <178084166.332205.1712919405648@mail.yahoo.com> <625b2dbb-6cb8-40dd-b7d0-fbce48cb5436@palves.net> <878r1e36gc.fsf@tromey.com> From: Pedro Alves Content-Language: en-US In-Reply-To: <878r1e36gc.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-04-15 18:02, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> Still in windows_nat_target::detach, we have an interesting issue that > Pedro> ends up being the bulk of the patch -- only the process_thread thread > Pedro> can call DebugActiveProcessStop, but if it is blocked in > Pedro> WaitForDebugEvent, we need to somehow force it to break out of it. > Pedro> The only way to do that, is to force the inferior to do something that > Pedro> causes WaitForDebugEvent to return some event. > > I generally like the Windows debug API but I can't really understand why > they didn't integrate WaitForDebugEvent with WaitForMultipleObjects -- > it seems like such an obvious thing to do and it would have saved so > many headaches. > > I didn't read the patch in too much detail, but I did look over it and I > read through the explanation. It all makes sense to me. > > I was wondering if something similar is needed for gdbserver? > I assume not though. It doesn't for two reasons: #1 - gdbserver doesn't wait for Windows debug events with a separate thread. #2 - in order to detach while the inferior is running with a remote target, we must be using the non-stop variant of the RSP (so we can send a packet other than \03 while the target is running), which the Windows gdbserver port does not support (and would need #1). ATM, I can only focus mostly on native non-stop, other than making sure gdbserver doesn't break. But after the non-stop work, the gdb and gdbserver backends end up a bit more similar in some areas, hopefully we'll end up being able to share more code later on. > > Reviewed-By: Tom Tromey > Thanks. I've added this and merged the patch.