From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yFmCByGKX2rxlSAAWB0awg (envelope-from ) for ; Tue, 21 Jul 2026 11:02:57 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=BRKvsKWW; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0710B1E033; Tue, 21 Jul 2026 11:02:57 -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.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED 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 125541E033 for ; Tue, 21 Jul 2026 11:02:54 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 887234BA7997 for ; Tue, 21 Jul 2026 15:02:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 887234BA7997 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=BRKvsKWW Received: from sonic310-11.consmr.mail.ir2.yahoo.com (sonic310-11.consmr.mail.ir2.yahoo.com [77.238.177.32]) by sourceware.org (Postfix) with ESMTPS id D0A2C4BA2E0E for ; Tue, 21 Jul 2026 15:02:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D0A2C4BA2E0E Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=yahoo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yahoo.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D0A2C4BA2E0E Authentication-Results: sourceware.org; arc=none smtp.remote-ip=77.238.177.32 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784646146; cv=none; b=R/Q3eO8+XXJ093grtfk5lnI5jsRfwphAMgS+DUHOLcT9CeG01trCUDltc6hQUL7rLoaqoAyfuQwmuy0lsfWnLW3StK/cRi6IVuWC9JiIjIdmY79+5k2m8x9+xsx+7bm+dxxwdZJfiZ3P6lgBSW3i8KtjAJ1qPwI+lcaJUuLP724= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784646146; c=relaxed/simple; bh=GbflwTmcydPSFLcPR0yAJikAncOipVqMvx8ZN2URaXc=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=PjmmnYxI/OmHrHmczUOjuhf8pH8pxbP3c0YkiIhdJR57Xo6Y20ay3NOhV12NUPMiNwPKpprl7oBfC26hZBHBPC3X4Q8fTxaWWw1dgCXE2BQT17hb0OI4pzxRgNwjec8/PRJgcj/jV2MHSZWt5psdDjbizMo86/ZbMTDX5mpe7sI= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=yahoo.de header.i=@yahoo.de header.a=rsa-sha256 header.s=s2048 header.b=BRKvsKWW DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D0A2C4BA2E0E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1784646142; bh=GbflwTmcydPSFLcPR0yAJikAncOipVqMvx8ZN2URaXc=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=BRKvsKWW+1BO0aUWHznVOSh33I6g2k/TUHqRHX7ssVFax4S7nMBbLs3ZqY+0rDBXwHSi0eFjdhwhfr1saXqU7KdF4fYtZeBBoAfBRRQaOR4wvAREBoG24W4dl1nYvXXyjHYps/mHIdvMzLA2VxBKwxkboeDvBSP9ZUMLkV27BqSX6dHwkv0wk2msqYn3cYrERTmtbPidNSpHkEfv7zt/zee5D/STvDyUXtV167nH7tU85d0y9Fo6VoXKNDVBEKLF7aJvTZLjYGnLLaIJpoEtp6gF3wBUHcYap1N5kFwwqwASvQqtR1aQUDR6Yqt9p3T0BeOoWyw2Yukp2IMnUlf5UA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1784646142; bh=2QjXnsXXCMHF9zgbrYv18fCsHSzMsQ7THh98nt0qI9J=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=p7mAe9NrCUbZVOYluPV6mXsOiD9x53kyC3tuQrueXM5ldm6uotW+USlKmTbMVK4t9aDtunfzFHa5Y9W+HjwAAzSDWd+EZTKIwUGWJ8MW2V+7go/kYWYinKNn7HmwmhbK3AVQS9AyyKpCElbGOlaz2WIQqhFdYNFVQ0S3KuxhMTQE04HH/+CsWtFHBBa0Wk6dqNRYgQ6+nTd9KEPCurA+T5TMjfcUM9A+QGYg1+ZUIY6XbYOElpH7gR9XJWwR1OscYjzFvNeOi729hUv9immNYemLpuwpuuGKWnImw1AumLJbKF22S4fuNXf6RolBUzz0WowA8RGzwBd5Du8JZoQ68A== X-YMail-OSG: 8h9TGPoVM1k1ct_20W62BJbCP7A0CF0dU8kYWkBPypVwDh7yyA6V..2Nai4vCvt f61BBrdGLWvoKQ1nVUpzaLhAkAdJ3x2RFrt4M4VScPZ5lZkL9EfwQznqCRQAOB5bdajZ8pM.VKHC FaA3i1MPu8OiVL9n46032oMlRzDuB6CeY3W5rO.F.RyZpqhdAdIsxsQbdYo6yghD2kdTwHm4b2vN 50fqTFYGQKtVnCMWtY5FlDWwaz3cvBWSRtoix8_0IYAOswnQvEbRj1q7Lw.NK9BCuFPSclt0QFI0 n0BCoYY5FDlRI5ncMk4XuD0TWj2AuKj4tdUjAdblYTAzyINr6h2xnNthftCscsbcuoYryb5TydhJ 1oLP6P2YsNbEg1bqxbaDRKC_tez4TFPnHDeYW5LastKHq.stk8cHG3bqmeFFbtE6l.YBHVVbWE7. 1OW_q8xiHcj9HoiqwJzCruFXuvRFkyot0ZJrNIgqFAmirSF7MhYSrMaPhfic.ZvcVvVbz66huXLh 1w3MvdlR7S8d6Km7XMwdIPElMmpNnCQCcZx7fom.MWeoY6ZV6C6ttCE6s4SyV8aR59mVUiBJciO6 Y4MH9_rsX.9lFmUIlAqEm9AmR4YpDywdahtwOC3JPUnfM_hDe5yFSOnw6IlqN8d8iQZn_qmiw5Bf LL64b2fWSmqQCwteDq3MePTXNnU0qMwshHAgaLLdkcwcqoSr.fC3sNGGlcqUnJKQLZE52bKycAsw zCKRZt3uNL.vfrgLkNPABTkf7OEfVAGAPs7NAPLwZOJDwE1wENd0WhQM6gnEDPuTnvDARzGM1hYf WjUEWnyrXwfUFCHVw6X5aSeqg6La_4yfSwsswzB7nxlgvI997ufgwkvqBTQKEHqXNsZwZA1FU2sq jgAyc_xT1zZSIp8cP5eHNDYkD.95pDtqeIeqEE7093gcBMDSk0vfpkAelDGTNNtKgyJ41e08y.7n HWylvdbK7Yh9MwV0mz6xn7KUr__ueP1eoS779Pn89QPOa9HnrKjXyMMLhSJWIJNXenIn_XVkkJXo aLPZ1GVquUefgIM5r8OELyx0ZziwFxCF4G0sN4SKsmNPVfZNeeKLmvNdRYVFDMK05A8S4PV3WRng wp5LUmLEAf.FcXz5.RuKqgdTAfPRVjyMhqHRivbQupWZvtstDnMqfQsruQe1evxGSCHoEDLElfTB cQNY8_iRZBfreA5YrOtIqNwAqxTDtzop9M11r5eGZG7v69C3vGGebou7Tczlo1PYKr7MS1LWiw_g goXGtIN2yBAJF2PnNEU9CHH6VtJTrYG0W.da1nWGJNhr_Uu9GIeoKtBkLS4nGLmD2yyK71UzRDVx f7F1WtGWbh1w12rGCH8fGS2vw0gd5PxkCam0T8eTqJJF4yYv7totucL3tfc0lS8Dzk7HQQtDtAvR iJPnGQ98D9jycPUYEuqz.PTGjvcraUPn9u4HWTTF6Z7T8PJ0kEiXo0kktx7.nRoyPHJ7hx_4Gv2z favhv.MdH_YOSrBNIlH51rAvFLhI4..R55NAqVIoVgGIICAKkO3mPjpYstej77xXiXOx.8oLG1cd u9CaGRpsJEYVKJ6G6hSpSZEM86abtHnSBNU7whl3PrCiAeuaDOItFTMmpjYPhUFeQbaKv2pomLKQ nxb7GJBuJMX7k210NJOh_7WyckMXvIK2pjVdR4IccCOUGpkuPRljU0xn7qtV9H45VQi0_aXzrotS qUs9r7k9WYHAXZD0umajTABHsf4wbjryZMv8RKSjmaOOqHmN4pgMkzcpZU.hYNzZK.fWuWevwxO. iKD05sPX4_e6su83O.F8v6LMSYLPIxPPzkNyZcEdTTKgx3vvUxegH83.6QYz.xvAiiH073fbsHye e6IL1elLrCBIFclyCMnHzIJLAu3uDrp9UNctwIKOJppKFnc9z3BMliwmua3XJTezhftsTBxVsPTy jV69lpTQuHD9hG8GdvTXbOhm072puqBWL3i1vTMKSEDrgPILhKo1a_xHaOesy3Vz927ygugSvNOY XwXC0.H5xu9J9Pv1.y4sgZzJGdMC2np9Rek8aEvgqDA4n2tVJq_F5zOXH6z0Qu7Po9wuNYYwOffL dv8aSp_t4fw8C8B_sY4mLJxdHHbMRhxglADYvg6wOlLET5XVe2a33GukmJwpayTQWz_sPnix4ers TK1iyJjdiF.BuRNDX8FHIn9DK8zhL9XjcDfKSOD4qzQUhoalRYDtDfz_cjTEQ22iFan1b41F1__N 94e2BiGyCQl3WDDI3eKHdook.ePblN25pgfg2EmDhN51YFKZGDDtZAKJ0FQ-- X-Sonic-MF: X-Sonic-ID: d49e3416-b22c-48fd-970b-084de798b32b Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ir2.yahoo.com with HTTP; Tue, 21 Jul 2026 15:02:22 +0000 Date: Tue, 21 Jul 2026 15:02:19 +0000 (UTC) From: Hannes Domani To: Simon Marchi via Gdb-patches , Pedro Alves Message-ID: <1822552016.1384378.1784646139252@mail.yahoo.com> In-Reply-To: <1448496673.3144402.1783350109140@mail.yahoo.com> References: <1448496673.3144402.1783350109140@mail.yahoo.com> Subject: Re: [PATCH] Windows gdb: Fix resetting of the debug-registers bit in ContextFlags MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: WebService/1.1.26180 YMailNorrin 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 Ping. Am Montag, 6. Juli 2026 um 17:02:35 MESZ hat Hannes Domani Folgendes geschrieben: > It's just great that all your mails are blocked by yahoo... >=C2=A0 >=C2=A0 > Am Mittwoch, 1. Juli 2026 um 21:03:09 MESZ hat Pedro Alves Folgendes geschrieben: >=C2=A0 > > 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: > > >=C2=A0 if ((context->ContextFlags & CONTEXT_DEBUG_REGISTERS) !=3D 0) > > > > > > And similarily, unsetting CONTEXT_DEBUG_REGISTERS removes the > >=C2=A0 > > similarily =3D> similarly >=C2=A0 > Right. >=C2=A0 >=C2=A0 > > > 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. > >=C2=A0 > > How did you notice this?=C2=A0 Like, GDB was misbehaving and you found = the > > issue, was it by inspection?=C2=A0 I'd be good to have that info in the= commit log. >=C2=A0 > I noticed because I was doing some changes in that function, and > CONTEXT_DEBUG_REGISTERS stood out to me very quickly, because for WOW64 I > would expect WindowsContext::debug to be used instead. >=C2=A0 >=C2=A0 > > > --- > > >=C2=A0 gdb/x86-windows-nat.c | 10 +++++++--- > > >=C2=A0 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 > > >=C2=A0 > > >=C2=A0 #define DR6_CLEAR_VALUE 0xffff0ff0 > >=C2=A0 > > >=C2=A0 > > > +/* The CONTEXT_DEBUG_REGISTERS define without the arch-specific bit > > > +=C2=A0 (CONTEXT_i386 or CONTEXT_AMD64).=C2=A0 */ > > > +#define CONTEXT_DEBUG_REG_FLAG 0x10 > > > + > >=C2=A0 > > Did you consider avoiding harcoding numbers, like: > >=C2=A0 > > #ifdef __x86_64__ > > # define CONTEXT_ARCH_BIT CONTEXT_AMD64 > > #else > > # define CONTEXT_ARCH_BIT CONTEXT_i386 > > #endif > >=C2=A0 > > #define CONTEXT_DEBUG_REG_FLAG (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_ARCH= _BIT) >=C2=A0 > I did consider this: >=C2=A0 > #define CONTEXT_DEBUG_REG_FLAG (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_CONTRO= L) >=C2=A0 >=C2=A0 > > >=C2=A0 struct x86_windows_per_inferior : public windows_per_inferior > > >=C2=A0 { > > >=C2=A0 =C2=A0 /* The function to use in order to determine whether a r= egister is > > > @@ -142,7 +146,7 @@ x86_windows_nat_target::thread_context_continue (= windows_thread_info *th, > > >=C2=A0 =C2=A0 =C2=A0 { > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 windows_process->fill_thread_context (th); > > >=C2=A0 > > > -=C2=A0 =C2=A0 =C2=A0 gdb_assert ((context->ContextFlags & CONTEXT_DE= BUG_REGISTERS) !=3D 0); > > > +=C2=A0 =C2=A0 =C2=A0 gdb_assert ((context->ContextFlags & CONTEXT_DE= BUG_REG_FLAG) !=3D 0); > > >=C2=A0 > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Check whether the thread has Dr6 set in= dicating a > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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, > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 update the debug regi= sters later when the thread > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is re-resumed by the = core after the watchpoint > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 event.=C2=A0 */ > > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 context->ContextFlags &=3D ~CONTE= XT_DEBUG_REGISTERS; > > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 context->ContextFlags &=3D ~CONTE= XT_DEBUG_REG_FLAG; > >=C2=A0 > > My bad, I suppose... > >=C2=A0 > > Does clearing the arch bit make the context be basically as if it was f= ully zeroed? > >=C2=A0 > > So if we notice we had a pending watchpoint hit, we were not writing _a= ny_ register? > >=C2=A0 > > That was not the original intention, for sure. > >=C2=A0 > > But OTOH, looking back at this, I'm wondering whether that wasn't reall= y the right thing to do. > > If we e.g., change the PC to point elsewhere, and then process the pend= ing watchpoint, we'd want > > to see the PC as it was when the watchpoint triggered, not what it was = modified to.=C2=A0 Same for > > other registers, as the watchpoint's value will very likely depend on t= he state of registers. > >=C2=A0 > > Right? > >=C2=A0 > > OTOH, if e.g., the user did an infcall on a thread that has a pending w= atchpoint, and we don't > > modify registers, and then the watchpoint doesn't cause a stop, not wri= ting registers means > > we'll not really do the infcall, and the inferior proceeds as if we had= done a "continue"... > > Not great either. > >=C2=A0 > > OK, let's just do what you're suggesting until we come up with a better= way, as it was the > > original intention.=C2=A0 I'm just curious for more details. >=C2=A0 > I did some experiments, and it looks like SetThreadContext doesn't care a= t > all about the arch bit, so it is working like your original intention. > I thought it would fail in the arch bit is missing, but I was wrong about= that. >=C2=A0 >=C2=A0 > Hannes