From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KZloHIlkRWoWiSEAWB0awg (envelope-from ) for ; Wed, 01 Jul 2026 15:03:37 -0400 Received: by simark.ca (Postfix, from userid 112) id 7039B1E024; Wed, 01 Jul 2026 15:03:37 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 C3D9E1E024 for ; Wed, 01 Jul 2026 15:03:36 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 050094BA2E18 for ; Wed, 1 Jul 2026 19:03:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 050094BA2E18 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id 6B19B4BA5434 for ; Wed, 1 Jul 2026 19:03:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B19B4BA5434 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 6B19B4BA5434 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=209.85.221.52 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782932592; cv=none; b=lkKwAS5GmCqAYK6F430S25GLRyWx3yMs7vpC7mAyqEYPZ6/1qxyzDMad8739+U7NwD1f1OpRImuZJImx91p/QPUk5vsETA3kdki/NRSo6ZMX3i3czzcs3hsBt+jzLhsX+7TgMrFv/uICAR3JyzJ/3BBgrZck9a0+zlNaFLAH2z8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1782932592; c=relaxed/simple; bh=Zmm/L00fgrcSBDsuTqmiZB4qsLIGi4oMxU4mHSshWD8=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=l6dOFXzjITatL61qd2y6iOdrljYSFpjuoQ7t6JJLLSBiBZhHLKdB+iAceg3BhKh+Z6q8LTs7nIi7x7c5eLXvPDJWIbhg7/S0Mp0L+Bgn56E6q/tIavxHXvgoCBSnHa4jc/l6ye7issGs/Kp7tiifvrZIlX3lzHSuBT0oYs7nAB4= ARC-Authentication-Results: i=1; sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6B19B4BA5434 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-474560436c3so934981f8f.0 for ; Wed, 01 Jul 2026 12:03:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782932591; x=1783537391; h=content-transfer-encoding:in-reply-to:content-language:from :references: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=FA4652B/luBO2G4AomouZigM6pEA75xmct0Q1vY5hIA=; b=WfMkCzki3uprckn7GTMsDzQTb2yIjmrKTN2eFmt0iHAK9YiFUulwPLBNpecj9H7ek8 qh0yMJvoVw82lzxKa2fKhVF6dVQMGELLqB3QXIx9TlNOgntGu90SyxtsyQLlKdTPWAQX M2o2dyUpYVXiNC/KqgRQGW8jCRLF4kwZu/AWMYbD6rv1YqdK7RuVFFZWM7qNmmFaG//+ jA6xUW8Rejvmb6GI+h6SPkawVph4JkZntbx0MxrN1oEyjql2vyE8FCThC49VoCoKhh29 yS52Ot+5Kx+r0rLBBPRyK2gQ34f/VZ4PK5TOOYv2wYPUiqo5FbxzBbdMy7TA1HXyWP+W uMFg== X-Forwarded-Encrypted: i=1; AHgh+Ro3Uj/JfNv4EyFij/HZBz1QklZqMJTwn5lHUjftxOo5opOGb3XCJb5/xp42xm0WVDg2T/DFzYLMoBUJeQ==@sourceware.org X-Gm-Message-State: AOJu0YylnQc0phMQV9swXoKGcyrRd76ya7VS8fAa+vCu3focMrCFxK/9 4RFa6PCsn9s+KpR24QTSS4jVX8gxuHaT/8s272vrVaOxqQRdBf9uE8jykwk0FQ== X-Gm-Gg: AfdE7clQ355Fxf8uhQo2eabpf4ZlFOyVg/iUUAd+i7CDhgwAnhguoyQb02ZIZKXOova r5QPo78V13ch42VMw6rx5KymFnkmz/HcOBa5YqciEZaTayN4uMVgTGShGXwgUsUzpDcCBU4mO6h jHmGZ1QZhcNZFuJESyFvTYmin2tFzudncEd1dAvmN+t0vB+IF7JHTMPeWrFOBau3Ouv6r/HhIqO WQFRsXzY1OozWtBdeKv0ag0voSM6mmXMp12jmhNhqO3Q9PqHzQASHOH9rgGGkIYYPYyulGj6NZy ONTR+b4jlh4SCByIVhwjX4WWObeTBcnfaFsFv2b+OSW6vthJOkgZAmwK9P4iwFGKT6aKPrvqcqs o7YMboZy3w2xaeY6DRqxePMGB5SA6b0684y8EPgk8JLxHXfa64NMXcrr/JmIfUNChPNmi1+1fk+ Waji6ukgbDsPubSWtrkcmXBwFPsbYihWdDZzxlNbPlWu6VtnUbldosrYNSFMklAK0DjQ== X-Received: by 2002:a05:6000:12c7:b0:441:1e8e:d8fd with SMTP id ffacd0b85a97d-477b110039bmr2325075f8f.29.1782932591194; Wed, 01 Jul 2026 12:03:11 -0700 (PDT) Received: from ?IPV6:2001:8a0:fac2:7700:16f0:8919:779f:a439? ([2001:8a0:fac2:7700:16f0:8919:779f:a439]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-477dde1a4fdsm2529019f8f.26.2026.07.01.12.03.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2026 12:03:10 -0700 (PDT) Message-ID: <96f2bcf2-96e5-46ea-9931-c9203415a9df@palves.net> Date: Wed, 1 Jul 2026 20:03:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Windows gdb: Fix resetting of the debug-registers bit in ContextFlags To: Hannes Domani , gdb-patches@sourceware.org References: <20260627142740.3995235-1-ssbssa.ref@yahoo.de> <20260627142740.3995235-1-ssbssa@yahoo.de> From: Pedro Alves Content-Language: en-US In-Reply-To: <20260627142740.3995235-1-ssbssa@yahoo.de> 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-06-27 15:27, Hannes Domani wrote: > The CONTEXT_DEBUG_REGISTERS also includes the arch-specific bit > (CONTEXT_i386 or CONTEXT_AMD64) which is included in all CONTEXT_* > defines. > > So this basically just checks if any CONTEXT_* define is set: > if ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) != 0) > > And similarily, unsetting CONTEXT_DEBUG_REGISTERS removes the similarily => similarly > arch-specific bit as well. > > So this creates a CONTEXT_DEBUG_REG_FLAG define with just the > debug-registers bit, and uses it in these problematic locations. How did you notice this? Like, GDB was misbehaving and you found the issue, was it by inspection? I'd be good to have that info in the commit log. > --- > gdb/x86-windows-nat.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/gdb/x86-windows-nat.c b/gdb/x86-windows-nat.c > index 27adeb1f154..3368814ed96 100644 > --- a/gdb/x86-windows-nat.c > +++ b/gdb/x86-windows-nat.c > @@ -42,6 +42,10 @@ enum > > #define DR6_CLEAR_VALUE 0xffff0ff0 > > +/* The CONTEXT_DEBUG_REGISTERS define without the arch-specific bit > + (CONTEXT_i386 or CONTEXT_AMD64). */ > +#define CONTEXT_DEBUG_REG_FLAG 0x10 > + Did you consider avoiding harcoding numbers, like: #ifdef __x86_64__ # define CONTEXT_ARCH_BIT CONTEXT_AMD64 #else # define CONTEXT_ARCH_BIT CONTEXT_i386 #endif #define CONTEXT_DEBUG_REG_FLAG (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_ARCH_BIT) > struct x86_windows_per_inferior : public windows_per_inferior > { > /* The function to use in order to determine whether a register is > @@ -142,7 +146,7 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th, > { > windows_process->fill_thread_context (th); > > - gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) != 0); > + gdb_assert ((context->ContextFlags & CONTEXT_DEBUG_REG_FLAG) != 0); > > /* Check whether the thread has Dr6 set indicating a > watchpoint hit, and we haven't seen the watchpoint event > @@ -173,13 +177,13 @@ x86_windows_nat_target::thread_context_continue (windows_thread_info *th, > update the debug registers later when the thread > is re-resumed by the core after the watchpoint > event. */ > - context->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS; > + context->ContextFlags &= ~CONTEXT_DEBUG_REG_FLAG; My bad, I suppose... Does clearing the arch bit make the context be basically as if it was fully zeroed? So if we notice we had a pending watchpoint hit, we were not writing _any_ register? That was not the original intention, for sure. But OTOH, looking back at this, I'm wondering whether that wasn't really the right thing to do. If we e.g., change the PC to point elsewhere, and then process the pending watchpoint, we'd want to see the PC as it was when the watchpoint triggered, not what it was modified to. Same for other registers, as the watchpoint's value will very likely depend on the state of registers. Right? OTOH, if e.g., the user did an infcall on a thread that has a pending watchpoint, and we don't modify registers, and then the watchpoint doesn't cause a stop, not writing registers means we'll not really do the infcall, and the inferior proceeds as if we had done a "continue"... Not great either. OK, let's just do what you're suggesting until we come up with a better way, as it was the original intention. I'm just curious for more details. Pedro Alves