From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6QAgJoPDS2pR6SkAWB0awg (envelope-from ) for ; Mon, 06 Jul 2026 11:02:27 -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=kwcB/aN/; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8B3D31E098; Mon, 06 Jul 2026 11:02:27 -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 D895A1E024 for ; Mon, 06 Jul 2026 11:02:25 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F40774BA2E0F for ; Mon, 6 Jul 2026 15:02:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F40774BA2E0F 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=kwcB/aN/ Received: from sonic304-22.consmr.mail.ir2.yahoo.com (sonic304-22.consmr.mail.ir2.yahoo.com [77.238.179.147]) by sourceware.org (Postfix) with ESMTPS id 285504BA2E22 for ; Mon, 6 Jul 2026 15:01:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 285504BA2E22 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 285504BA2E22 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=77.238.179.147 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783350119; cv=none; b=QnQzXYK03PcRW5YGO0fubFLfBHNcqlhnej80y3nj9wObpmvw4OfXBKY1NfiKM+uRJWhRdvqcQucRZY4nQjHtWJQLzpdRlaXURBNJYfoPGGHjgIEsy2dg4XalGfeY2Mme+CE2Mn4HYN+5f6tG9a4WtdRyRsQFsfNwTf5TmFYwCRQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1783350119; c=relaxed/simple; bh=Ph8gDDQYSAhkaTZf3S2Mub0+CF90NxZQrjGOn3d3aIU=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=Ai1Rv4VVo8g9gy1bDVX8jIl5HUP09juK1PnRJFRbcSy1HMPPSonr52/MLRqV+pLwFnxRXs4I5h9CNW8WpGACuXtqPUOZicf62Dz/KygR2VNgOagc8uJqF+8fGvOY7KcURxe5ooB0YQ/9eiDkkg8DlF8+7IuwtuMCZ7omTiPQdsI= 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=kwcB/aN/ DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 285504BA2E22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1783350117; bh=Ph8gDDQYSAhkaTZf3S2Mub0+CF90NxZQrjGOn3d3aIU=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=kwcB/aN/X0ata3YJIXz9yz1e97TQTDByPwt9aQAQuJe10BFO3/oeaqZaeuBiQ2xgG5853jQnsQhL/eoLpBHtKWu8CVk4ezojuAdNMUfTZ/6nUIRXR8dk/wsQeFDlI1hfpsYf0uihi2K96bGe3+XHeDUlFh8l1dCNGl0by9hKRJ6x9wfEBD6A/s+aNeg1G1unrzzoNSJKeWaFlpqDoLnnZArLAZALSPxMqkgp2FLqCq7ogRtPkbX6vGLpAjynV5b5FsdUjHhFx/MSEa0KyUCVvgo1d4vH2n9FFzl0f0j4u2XZX8OOpIkyADP75OFm2Y3JLQKfSadQMOqCcmITa4439Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1783350117; bh=zqD4dKpAIOOg9v1Q5qZcL8PyfNxF0iDHPeiQGfMFMB3=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=gELyRun1T+MfBD6LdKYSAXyclKTs9Srj+F/gV+/UKPYvlF2TPBuO+eB2aDBVOBJbk/I0ALpgI7PnlpJ6gpKKnbNzJjMicJqH2g6mQInrwpqww4+pXKc9gTGp8HrGYr4Tla99aiddg8SpidD4DRv9wTiepdOp3NnypuX7rEDnAQfRszg88pAVVnWGUYnGW6K3TLTRbaQdY32lMGeW58kmUtEvbBxdikZ2X8T+ROJ4+m60XOZKyWN9Ic8hPVtwwWg1CldKSLmQZkqq0t16katqBD/7sLOEscikkxBDj2WZqXxmKO4c0AYCNoQFNs03i+UfLhxdVi7eOgmsBXp0Nph95Q== X-YMail-OSG: URTSg4wVM1k3jUjgB39PwdIyXUfkRe2YL4lMo0yMv49aLLIG1jjALyE1Bo2L.x8 tcrAjv.h9SAIsxXd.cgvZ5Gz71CyByiBPL91I2UKUg6YfHI6VAjC2Y1__WGOfwR3wfc2mWGdlfzD L2WKPn4jBEDHfpca46f5cZX.UMtQAYOuRsMnO9bGt_PThLhfquX.nAESjUg3gNywlGCXVrmk24Hm xt_1g7HnY5gaXyRbSuHyLV.7EVNf26x7DaaO0tWkyaVV4klIEVJFTQmqeGSZpBCByLiF2ZNcXoAK yiXlHaxAGD.mpfgB9qYhReX6_JD_WplkytVEjCIe1lDJZmjB3vW0J9WEfgTgcWVS5CF1rbjB1dQp 2a_3GBRQ3z6k9uJr51ww4DHOf.Xnxage9iE30lvS72oab8dKIC09imBwcFPaZ1fus5AkDBFuPxHm POSb9GfmIZcBPQVL7XUNuvRACDJckB64YuZ6_j4ZfLIbd6UqwEmlXMUjsU.fQEXj57HFbrdNFohh JJfiwaZLB.VtdVOLJbQx6C545uge_03yK0LRyeYgp26sVWkTbr5hTAGBGzPFiAGk0SkiOKOflPA5 8IEtx87dWR7QyZQvdEqBnvygAYFTMHRRmRFnDVopZx2EegJJq5gBJcoe9lV6W2W7GwbTgdRE8g4f VISgsf_xIUDVnQ.IosxGQ7KX5Eg.O8Yq_y23hv89F2WU1uvGr7j2F1Br_aqblgJToZGbnTOVJyua YVlOrk2vnATE3mMRtO4cIikbB6FCfe5GGwC6C5v.UtVVOvA34.z0FBPtQkvvMk6nPM1Shoq98BCe y88IlVtVp8tvl57EiQriCA6c4Lq4ybS3O9OF_Rbkc11Y1bCpFX7IfIggayjUVF.9WGtLgNyHva5a fqwbinI88EjgECdGajxfwPjBtUs5zh24ztTZQbUV4MseDhmYpDk9HNwEaXLFEpSB9sOCUpnB1QsY IzonZhJZsCCTGsj8pObs0jbVWNohTD1Kh7zaAdpMcCBpRJIQSoPAtzqVjI8wag03KtcbCaIqHY9a 0KCSwTrL0X_PAD7.6ZMWkoAK7WteTNQAAFDjDFUzOiCH7T2qlJe7JJ5BE6pbJYOFaqPUDrNwojOF vARAt8Asgleqk8FHp_xl9zaJQZXsZme8BxTsMWe6al1vNbxG56k1i2kgD3iGjrHB219d8dcN5Swo Q6UALtlu2Mft0t0akdUrJlMlmUII8VyOGhKqABNaN.Md_rpCZd.oBwoVEAUd14He9fuUoIwZibEe tMiDEbqNb0EZ09VUyPX.xnKmc.aRa6_ou0LOmH.l_OyRcxq7rzQ.6e6jmpuIuKCUCxkFWGgyALkM hZIplSYcsCy3EvzhnubRsXSFbIqSS9UPt9PkeUrPT.VUGc4XDlMmweaG3r7ZTQbThXMIW_dg.t0Q BGJviAo5RQ1PMgrIMRhSaJaFIHNp3S20OVlIt7HFTUPDCnyiz0WwuhUTbczGTmz7ELOxixwcVY10 Ct9dCaDcYSK8YjSOia05cI4J3bceLd1BCYiwcrWRWRoA1Jl95ttde42DHmWYRzjI0HvkyFOxnQw0 xyptFCWj7l1.TuBzxrYTwVoY222zqqUHm87Sz1Ill19Z4.wV58XQOK55WBEn_A0e9B24AbkPbwD4 xxYlUTX_buXdUuzF3TlUnrM8Fv2U9doNobxNJAG6Y7FHgUHtNhyqbChPcZFVq4e_GCE6srW8OF3e Y2cHJrYOuZ9ajxvQoMoZB0IucmlQS74Vl.gyEhVFQiBQmtbiRWh2YnlGED3b89_W90fkmZPI7XLV IWhj4TFARyEMNfmhtfUp6NzlT7EaUfVPW5x247WhH5xINAC3OUp6BPPpQtffBk99Riv4MMVbpLGL k4lrys3NyVDkPcp8_.QcnSS8QLtkHapUO6V_kjpD3kYdeUdN1N1dFbMGg4OJXQqLeJ.FxOflXafw peHb1pKLZOcw8wVdf_qugQkJ6eJarnR41NGrlKyPgNm96tZ_PFQu4wymgGx0G4irLFJ5RBG7b3gh oeLqVF8OFQVc45bB4nR_qpULUEspQouI0OPb6TZxNfd.vmVSyEZdMcOdMGIX69ZrG.HfzFQDsAbG i8J2Plp2OEddZ9u4tcucg1UaGEV6KE6c2dUPmxrIrU65GMi5mbLAaHan4mXpz_8HJAr6MkNwIGuJ O1UJrdMe0la4sfwBcxAFwHZVqCpdgUudxfhlc68eWFNGjwCt1brh69XUqPBXs.Py3T4KLLbDHjy1 lK5uHWiRnN.eb3EoJKbPaZbnUU4xV8x0xBDpe7he67nK21AK7PPuM_.tccLpN X-Sonic-MF: X-Sonic-ID: 32eeb9dc-b099-49cc-b6ac-04fb5be17293 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ir2.yahoo.com with HTTP; Mon, 6 Jul 2026 15:01:57 +0000 Date: Mon, 6 Jul 2026 15:01:49 +0000 (UTC) From: Hannes Domani To: Simon Marchi via Gdb-patches , Pedro Alves Message-ID: <1448496673.3144402.1783350109140@mail.yahoo.com> In-Reply-To: <96f2bcf2-96e5-46ea-9931-c9203415a9df () palves ! net> References: <96f2bcf2-96e5-46ea-9931-c9203415a9df () palves ! net> 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.26086 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 It's just great that all your mails are blocked by yahoo... Am Mittwoch, 1. Juli 2026 um 21:03:09 MESZ hat Pedro Alves Folgendes geschrieben: > 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 Right. > > 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 th= e > issue, was it by inspection?=C2=A0 I'd be good to have that info in the c= ommit log. 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 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_B= IT) I did consider this: #define CONTEXT_DEBUG_REG_FLAG (CONTEXT_DEBUG_REGISTERS & ~CONTEXT_CONTROL) > >=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 reg= ister is > > @@ -142,7 +146,7 @@ x86_windows_nat_target::thread_context_continue (wi= ndows_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_DEBU= G_REGISTERS) !=3D 0); > > +=C2=A0 =C2=A0 =C2=A0 gdb_assert ((context->ContextFlags & CONTEXT_DEBU= G_REG_FLAG) !=3D 0); > >=C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Check whether the thread has Dr6 set indi= cating a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 watchpoint hit, and we haven't seen t= he 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 regist= ers later when the thread > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is re-resumed by the co= re 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 ~CONTEXT= _DEBUG_REGISTERS; > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 context->ContextFlags &=3D ~CONTEXT= _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 ful= ly zeroed? >=C2=A0 > So if we notice we had a pending watchpoint hit, we were not writing _any= _ 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 really = the right thing to do. > If we e.g., change the PC to point elsewhere, and then process the pendin= g watchpoint, we'd want > to see the PC as it was when the watchpoint triggered, not what it was mo= dified to.=C2=A0 Same for > other registers, as the watchpoint's value will very likely depend on the= state of registers. >=C2=A0 > Right? >=C2=A0 > OTOH, if e.g., the user did an infcall on a thread that has a pending wat= chpoint, and we don't > modify registers, and then the watchpoint doesn't cause a stop, not writi= ng registers means > we'll not really do the infcall, and the inferior proceeds as if we had d= one a "continue"... > Not great either. >=C2=A0 > OK, let's just do what you're suggesting until we come up with a better w= ay, as it was the > original intention.=C2=A0 I'm just curious for more details. I did some experiments, and it looks like SetThreadContext doesn't care at 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 t= hat. Hannes