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 61D88385800D for ; Wed, 1 Dec 2021 10:40:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 61D88385800D Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-81-b245fPLWMgGBYySvFPShAw-1; Wed, 01 Dec 2021 05:40:27 -0500 X-MC-Unique: b245fPLWMgGBYySvFPShAw-1 Received: by mail-wm1-f71.google.com with SMTP id 201-20020a1c04d2000000b003335bf8075fso12061092wme.0 for ; Wed, 01 Dec 2021 02:40:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=kkAEwnqfbKekHkB3eCg1BEaNWH+QFJHQsZKEJmnS9xc=; b=mgFf5f/gDOdHCIsVGoaa/LLGNniKCIVDztu7WtKrLGsN7RMthuaDiwYgMLNUvgSlUu s/Hd2SpOoMGzxqovrEwMlCo8nju6G3plVH2MUF45WWb3FDexWH3UW8Oy9bWJ+vKwx1Zr MNm2QhxYLkEhBWwE6vqLN6Ux/9tlxfw2JnFHYhOaKM59pJgqUbJCVz+6v+t9K9G/N/Mn s999Rzj69fF/cK2jVOM8uupHYkng9XFLLeWMMFj2U431z/Eb+10NVFE1bJ5HOMQ9cg1u SpBeF/3O1piiAmz4qFLYjGmEC8P/SeSOqX7CCnOvkgZuPXfsFfTGU7/b89R3biB5mMzI cB2w== X-Gm-Message-State: AOAM531DfxXcP1+sFq9hvqZlaJoqxKV8/1JIOyqXsZYEpF4wluxxVO98 khLDmP9kqyWUdb4jnfV2ZYOvegTlQRTK8A036M6NFsznlxXzGSP6LD4qYA97JPET4uxqKIC0FKR N9E9SH5JXXahUf7E71PoJIIEQXwEOQQ1j8gSWmEvY25/lkG39EdgHQi//2LzyTm5YJiGPqmIiDQ == X-Received: by 2002:adf:d22a:: with SMTP id k10mr5975322wrh.80.1638355226095; Wed, 01 Dec 2021 02:40:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJyIVUIsWay93xL8NP8oknmjHT5A4vwxZdJJS3zhlpAGoDayKGH357c87700O5448zvefFAbNQ== X-Received: by 2002:adf:d22a:: with SMTP id k10mr5975293wrh.80.1638355225866; Wed, 01 Dec 2021 02:40:25 -0800 (PST) Received: from localhost (host86-134-238-138.range86-134.btcentralplus.com. [86.134.238.138]) by smtp.gmail.com with ESMTPSA id e12sm25170159wrq.20.2021.12.01.02.40.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Dec 2021 02:40:25 -0800 (PST) From: Andrew Burgess To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: [PATCHv3 0/2] Improve 'maint set target-async off' for remote targets Date: Wed, 1 Dec 2021 10:40:21 +0000 Message-Id: X-Mailer: git-send-email 2.25.4 In-Reply-To: References: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2021 10:40:42 -0000 I pushed patches #1 to #5 from the original series, but it turned out that the assert added in patch #5 would trigger in some tests. I checked my cached results and I definitiely wasn't seeing that assert during my testing, so my original assumption was that patch #6 fixed the cause of the assert. However, upon retesting I found that this was not the case. After rebuilding my development branch, the assert was present. But it hadn't triggered during my testing. I honestly have no idea what I originally tested - it clearly showed the expected improvement for native-extended-remote, so it contained some version of my work, but obviously not patch #5. Which is why there's been a delay getting a new version of this patch on the list, I've retested the remaining patches, then double checked. The old patch #5 is now patch #2 in this series, and the old patch #6 is now patch #1. Patch #1 contains a fix that allows the assert in patch #2, that previously caused problems, to now be just fine. Changes since v2: - Previous patches #1 to #4 are now committed, - Previous patch #5 is now patch #2, - Previous patch #6 is now patch #1, - Change in remote_target::push_stop_reply, the async event token is now only marked if the target _is_ in async mode, rather than if the target _can_ be in async mode. When async mode is later enabled we were already marking the event token, so this should not be a change in most cases. During remote_target::start_remote however, we push events, then process them without ever enabling async mode, this use case was what was previously triggering the assert in patch #2. - Code is otherwise unchanged. Changes since v1: - The old patch #2 is removed, as Simon pointed out, this was just wrong. - The old patch #3, which was approved, is now patch #5, and is unchanged. - The old patch #4, is now patch #6, and still needs a review. - The old patch #1 has been split up into #1, #2, #3, and #4. Given significant changes since V1 these should probably be reviewed afresh. --- Andrew Burgess (2): gdb/remote: some fixes for 'maint set target-async off' gdb: add assert in remote_target::wait relating to async being off gdb/remote.c | 192 +++++++++++++++++++++++---------------------------- 1 file changed, 87 insertions(+), 105 deletions(-) -- 2.25.4