From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kaM5EO2kW2rUsREAWB0awg (envelope-from ) for ; Sat, 18 Jul 2026 12:08:13 -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=ZSPJSlKu; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2394B1E033; Sat, 18 Jul 2026 12:08:13 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,LOTS_OF_MONEY, MAILING_LIST_MULTI,MONEY_NOHTML,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 1BA341E033 for ; Sat, 18 Jul 2026 12:08:10 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CF5FC4BA23FD for ; Sat, 18 Jul 2026 16:08:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CF5FC4BA23FD 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=ZSPJSlKu Received: from sonic306-20.consmr.mail.ir2.yahoo.com (sonic306-20.consmr.mail.ir2.yahoo.com [77.238.176.206]) by sourceware.org (Postfix) with ESMTPS id C6D164BA2E13 for ; Sat, 18 Jul 2026 16:07:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6D164BA2E13 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 C6D164BA2E13 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=77.238.176.206 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784390862; cv=none; b=Rk9MMv4IZdZqX+VvyoXaMUtu3B6huuG1pXX2/S3kWIf3gamlMXwq4eKFkWsLXmnpEqVP/rBdsPdTMXC9fPw16pR/LX7AsPwXmiIeMivE47Jb6VUpOOGjsOjLsCad0J09RYX33hbn6pw0pvtxus4nF3gJ1sTHERbWuxwmZybaHvM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1784390862; c=relaxed/simple; bh=uSzeHVB2hiNeFUKqRtm2Vs9FUCP0euvgbG75fuGPawA=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=Jiw0SyNeCZwlr+16Q0KCHomIp9DkN/CSYwdbH4Uqbzj42yP1Gjze5+Jd+C/6kckk2K620XwfrZvCkurHBx2GKcjBqobaYoohCIXua3n8HHlZ9FufWdY/70BX9yxkI50dCxZhZF9NvFrZjD/nn14M5gpmYsaPeR6KPyUE9CYxKY0= 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=ZSPJSlKu DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C6D164BA2E13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1784390858; bh=uSzeHVB2hiNeFUKqRtm2Vs9FUCP0euvgbG75fuGPawA=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=ZSPJSlKud+Fq8r8M+bnMo5WPXbRxxTjtzZry6mUIGNH7dBWOOTDbI7R5W7cupZeGCRFAiem7dJ2wqb/IQR7qUe5fCtYIk221jnz+Rjj/LWRG77AyqZm84mmPyaQNkdvdEgrROujqc21vMpie1WWNM0KtPjs8llSEWPUMq9lxgitWGdo6HEoJkFy1gBtvPY9rhdk0eGzWD8cb/VWtQXwklZ8Xv/XruQIGwWrhp6YYrjSnpQWjyAFPBjhOkc1vJa4Dn/iBj1IxNFmFJULKUSCxTMlu4WUcOVNdn2fI64k9H5w8b7zG4hkwAvGGPuqJfA9Y3tFJnPKUqL1UgFgqGvfd0Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1784390858; bh=8eNv7WmIplWiJGJECrPmLh/ADo8aQTC36DsskllCi7Z=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=bu2I8RHPG5fiIBgjHGLE5QLJqQO3pcL5VUpc8dmydtC7qG1O7uQmYbHETqGOiAEhe8Umtx1qOyR3qxUPpZ6XqR28FJdEys9v8ngoZBSoYPa4xwViTZSVylMMW6Nl5U1kxwEDpUavMvG03vCtIaO35nK1AOMb8ogx1LJbAgLCLjjxsT/7wlqfXSgbxoLBdnsTxSxL2MHRTYK4g1ws2XlrL5YkgbaC2D9FePi2txXhapvjGh2hmJr6/SYaL7/fycKanPlMTLkJvP+MyyVaO3JcslMxRboBVEJG2fh9wUiXm3UU4CXRVy+6do4L2iSKZaewcEPVo/DcAkRxYD4GJwtpRg== X-YMail-OSG: 0ro22JMVM1m3aC159A3EpYRWfLYNNoM3RAc.fbe7AF0jpRCZ2sTNic4f4HJAh.E Ee2SmWneLm2ytVFzi.b3f9ZBOc.zAtLlcbz0YQoFfHrsXTWyiCiqrZt7m9ljrhQ2495HS1Evh8m6 jzCCjJqSdUR9JbNCpEBWMa17rObjIertSRe1U78yTIGGo_B6Y1MI4J5v57ZA38g9qhAwKhR8kA8i 3T7eU_lIcUbhgZU9O2OFpd4u5nRGYI44QLRZ50eRthmUT7LzvV6W6mc6qeLVS.OZUFNeYj9QBqoa 33TUkMWY9TXwy7zkRL.dQfosVPV67ZRlBXIO9bpx.jJmM6ehOwvNUuM0vhIw6Dd.Zw5tJp00VxZb ESVU0c06eS.bvY.ESLHfyMl2lZSWhROxXXMcjhuWUgm9UTq5yTiQ.bTBzAdJ_qYwFsPDm_iAnPI2 gzaMgMxkePmo3eoV7us49xf9SRdYUTnbm0EQOGmRLURXaVFaymfR8ia1zQAb1kcHz3abi3KywEDf s8m1B6N9z86lkB55KoAQmyvJ3ACQbM1oKaMXonbLWqkN_KkckZ1oPwn3fNoJo71_5Ki4qZ_tMDA7 L32rADRxyUjLOYCitEisYLa6kZ3zgGdCsSEUCDHDik9WLsx9sA2D1daVWWoJRfyN1M39Bl17tVgQ kM5hpfO0s6S7EWiGpao6amIwEO6eY.rNpimVsSMbfEnoPhZ7.jpbqbFdlSeF63HfkNLUsFCbx8ud ChHEZvpZg81AcaBBGGqcl7l8IwuozksvBT_auJLsukvIcnc5YpsIGGHW_7RvePLXYUSMAdXTLDVx hDyJu4NpdXDXciPjFkq1ZnSce_xSgMPUDJC0WkDtTZCuQdKctOLbshC1q8MToOWwoDkdH_sEDs7C bwSTP1.DC12H8uV_JBpD9iDt_hMlBDq9n0SeinIXKV6QPFhdj6tbdLbIE91InQsHPqE2k0Lw3fSy E2LNreJ6B4fRJRq5BdNZIo0yR2xYiPfo8FAmYyv2tBvu3GTBkfZ7aIAv7MGDa9w9zIAhcXfIDm14 K9VZi0AkDwG1IUkspwrGJeWrFaH9R9K9EE57VMVZfhatmUjEkq4VCdPEfo2phmGVFMfX3LxEKtdY 5ruwWCgz3NRMCgQZgl6HP4rcBWtGAuDMnRQWmwNdD2w04w_RjcjrrKg1xRguvQSvERjaYDaNEQk9 N74K367ER0pg5JeqSs_xs746VBAR3FZTkA3DsJmYlro6EnkbLGp9D7FWYfVjVKOy9IF0ZNPW0uyk 8uBiXNMObOl49d9f3FbSsZjV3nzuLeVAYGH3UKxVjQOaRRbfhd5sCaDvEdJ30SDwH1D3FpDlhZKB U_48LL55Z7g7EIV2JdESqx2EBxp6Vvk9L4fm1rrqY40lzteCFM7T1aF3ZS3zsv_HThMqcLfw2FtQ 7P7mpCtZ.A0EVp9SM178yMN4gLkmTKpoReDo0qyhZ511P4xgYtUbgq4urHu0fOCSeCiDMvrBzsJ1 d5Zxlt9HzGwKZscV.KXYfnNSH71mv4kHM_SMD6xMmTM5ynOLnwRyYmWITRKq39I6qcbZtsqS8oDM fhgrVp0uwnnnHsxUmOStwhtYg8vwlSytJN_3MLlSuSfHQczJCjMSJEPnqWmFeN7kt8UL7Bge5_gN 7FMm4a87ZJDNyFzQ6Ud.Pau2.2ECTd.nuIoNFdEP7ytcENr9Bn3rUJv6WMnAzyHh59BLQEubC6tS aNNmsZQmtXo25WNC_LEUyceEr6SKQ.2ysJAgk2EIwb9rnNz4gAQqglf.uxg3uXYrn672FYR4DcEI YXtNslHueBtdyee8I5dkmhYgPlbRHAhfdGTZWRboKE3k2pTJEUCrtx3sR9L3Q139MXUFaJNuQ.5w WBX8XG_Da2x5YEVsSwdSyH7tbqD6UfEafQXA9WtDQxjh1oFul.A0SqRfk_cx9cKICuW2NxKR9xRH Seohl.zwtG9_HjhfnXnqsE5iHw0jUvacNkdP0Qy.K4IUH1e.JZjbzVEYvNi.go3TxJ7pKr22JsUj T3a6be0tztOowhNQzkAb3Uhh0900uT6p0zoMa0CK263ddbqKdpH.CVbPzTGalkz8s1KUgwdihpS2 9POxUXfmBe01XRfAgSocJMh9oMHYlgZh739igHUrn_zPNz4DJ4ebF00SpRMu7Qil6wD6SKhzshTh CAMmUbXE5PbLDfT6XY1lQWpmYi.3b_Zv4r9QDjnpepEEqDGOpN3Zbd4QegXWbh.ZXMCq9R25KVmM h33tANZL8y_DwkCDGCiXcPj9NQjgseDhPSQK9bwIT.CCn2J5sImfEx7maYzHn0JeS8e_D X-Sonic-MF: X-Sonic-ID: 07b4c9f5-e303-4cfa-b983-0f85faac606e Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ir2.yahoo.com with HTTP; Sat, 18 Jul 2026 16:07:38 +0000 Date: Sat, 18 Jul 2026 16:06:48 +0000 (UTC) From: Hannes Domani To: "gdb-patches@sourceware.org" , "Schimpe, Christina" Message-ID: <711725229.188625.1784390808447@mail.yahoo.com> In-Reply-To: References: <20260712113229.3695246-1-ssbssa@yahoo.de> <20260712113229.3695246-7-ssbssa@yahoo.de> <1783589955.3451825.1784296008828@mail.yahoo.com> <1971012298.3491204.1784299790735@mail.yahoo.com> <1319283533.3531812.1784305616658@mail.yahoo.com> Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel AVX) support 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 Am Freitag, 17. Juli 2026 um 21:06:16 MESZ hat Schimpe, Christina Folgendes geschrieben: > > -----Original Message----- > > From: Hannes Domani > > Sent: Freitag, 17. Juli 2026 18:27 > > To: gdb-patches@sourceware.org; Schimpe, Christina > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel AVX) supp= ort > > > >=C2=A0 Am Freitag, 17. Juli 2026 um 17:26:14 MESZ hat Schimpe, Christina > > Folgendes geschrieben: > > > > > > -----Original Message----- > > > > From: Hannes Domani > > > > Sent: Freitag, 17. Juli 2026 16:50 > > > > To: gdb-patches@sourceware.org; Schimpe, Christina > > > > > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel AVX) > > > > support > > > > > > > >=C2=A0 Am Freitag, 17. Juli 2026 um 16:16:31 MESZ hat Schimpe, Chris= tina > > > > Folgendes geschrieben: > > > > > > > > > > -----Original Message----- > > > > > > From: Hannes Domani > > > > > > Sent: Freitag, 17. Juli 2026 15:47 > > > > > > To: gdb-patches@sourceware.org; Schimpe, Christina > > > > > > > > > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel > > > > > > AVX) support > > > > > > > > > > > >=C2=A0 Am Freitag, 17. Juli 2026 um 14:54:59 MESZ hat Schimpe, > > > > > >Christina Folgendes geschrieben: > > > > > > > > > > > > > Hi Hannes, > > > > > > > > > > > > > > Thank you for working on this. > > > > > > > It appears that this patch uses the same commit message heade= r > > > > > > > as patch #8. Is it intentional that these are separate commit= s? > > > > > > > > > > > > This one is the gdb part, and #8 is the gdbserver part, that is > > > > > > stated in the title. > > > > > > > > > > Oups, I wonder how I came to that conclusion.=C2=A0 Sorry for tha= t. > > > > > > > > > > > > > > > > > > In any case, IMO, commit messages should not have identical h= eaders. > > > > > > > Also, this patch seems big enough for a commit message which > > > > > > > is not header only. :) > > > > > > > > > > This part still stands for the commit message. Since it's not onl= y > > > > > avx registers, I believe it makes sense to share more details her= e. > > > > > > > > Yes, I will do that. > > > > > > > > > > > > > > > Do any AVX-* specific tests pass on Windows now? If so, it > > > > > > > would be helpful to mention that in the commit message as wel= l. > > > > > > > > > > > > I actually planned to add that info, but forgot. > > > > > > > > > > > > These tests then pass on Windows: > > > > > > gdb.arch/i386-avx.exp > > > > > > gdb.arch/i386-avx512.exp > > > > > > > > > > What's the state for SSE=C2=A0 (gdb.arch/i386-sse.exp) ? > > > > > > > > i386-sse.exp works since patch #1, it was only a compile issue of > > > > the test itself. > > > > I will mention this in the patch as well. > > > > > > Thanks. > > > > > > > > > > > > I also saw you introduced some code for PKRU and the shadow stack > > > > pointer. > > > > > We have GDB tests for those registers, too: > > > > > - gdb.arch/i386-pkru.exp > > > > > - gdb.arch/amd64-shadow-stack*.exp > > > > > > > > For these I just added the equivalent code as is done on Linux, > > > > without really knowing what they are for. > > > > > > > > i386-pkru.exp tells me: > > > > > > > > (gdb) print have_pkru() > > > > $1 =3D 0 > > > > (gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support > > > > UNSUPPORTED: gdb.arch/i386-pkru.exp: processor does not support > > > > protection key feature. > > > > > > > > Do only certain CPU's have this register? > > > > > > Most recent CPUs should have it. To be sure you can check if the > > > corresponding bit is configured in xcr0. > > > > I thought that's what have_pkru() does, but I might be wrong about that= . >=C2=A0 > Yes, this should work for windows, too. >=C2=A0 > > > I believe for windows this should be the mask returned by > > get_xstate_features_mask. > > > > You probably mean GetEnabledXStateFeatures, but yes, it also tells me m= y CPU > > doesn't support this. > > > > > > > If your cpu does have it, I think you must look at the test in more > > > detail to find out why it's unsupported. It might need some adaptions= for > > windows. > > Google tells me only not all recent CPUs have this, is mine one of them= ?: > > 11th Gen Intel(R) Core(TM) i7-11850H >=C2=A0 > I would have expected this but cannot say for sure.=C2=A0 And I don't kno= w the state for > Memory Protection Keys windows support. I have tested this now on another PC, one where have_pkru() returns 1, so this CPU really should have PKRU. But GetEnabledXStateFeatures still does not return the PKRU bit, and I can find no equivalent XSTATE_PKRU define in winnt.h, this makes me believe that windows just doesn't support this feature. So I'm fine with removing that part. > > > > And amd64-shadow-stack.exp: > > > > > > > > (gdb) print $pl3_ssp > > > > $1 =3D (void *) 0x0 > > > > (gdb) FAIL: gdb.arch/amd64-shadow-stack.exp: test shadow stack > > > > support > > > > > > > > No idea if that should work, since Windows is supplying data for th= e > > > > $pl3_ssp register. > > > > > > > > > > > > Hannes > > > > > > Without knowing any of the details in windows I believe adding full > > > support for CET shadow stack might need some more changes. At least f= or > > linux, this was the case: > > > https://inbox.sourceware.org/gdb-patches/20250821171029.1555603-1-chr= i > > > stina.schimpe@intel.com/ > > > > > > I believe it would be better to handle this in a separate patch-(seri= es). > > > This also applies for any other register that you add and whose dedic= ated > > test does not pass. > > > > > > Does that make sense to you? > > > > I was wondering if it isn't the compiler or linker on windows (or maybe > > windows itself?) that doesn't support this -fcf-protection=3Dreturn stu= ff. >=C2=A0 > I don't know the state for windows but would be curious about it. :-) > At least for Kernel Mode, I could find some documentation for it. I did some more tests here as well. It turns out binutils/gcc really don't support this on windows yet. To enable this in the executable, at least a special marker bit has to be set in the Extended DLL Characteristics [1]. With msvc you can do that with the /CETCOMPAT linker argument [2]. So I compiled amd64-shadow-stack.c with msvc and /CETCOMPAT, and tried it out with my gdb build. Before I always got $pl3_ssp=3D0, and with this new exe I always get $pl3_s= sp=3D1. So I had this wrong, because LocateXStateFeature returns for XSTATE_CET_U this struct: =C2=A0 =C2=A0 typedef struct _XSAVE_CET_U_FORMAT { =C2=A0 =C2=A0 =C2=A0 DWORD64 Ia32CetUMsr; =C2=A0 =C2=A0 =C2=A0 DWORD64 Ia32Pl3SspMsr; =C2=A0 =C2=A0 } XSAVE_CET_U_FORMAT, *PXSAVE_CET_U_FORMAT; So $pl3_ssp showed Ia32CetUMsr, when it should have shown Ia32Pl3SspMsr instead. With that fixed, I tried again debugging the /CETCOMPAT executable: (gdb) r Starting program: C:\qiewer\git\amd64-shadow-stack.exe Breakpoint 1, 0x00007ff725812e41 in ?? () 1: $pl3_ssp =3D (void *) 0x4feff0 (gdb) x/1i $pc =3D> 0x7ff725812e41:=C2=A0 =C2=A0 =C2=A0 jmp=C2=A0 =C2=A0 0x7ff725817680 (gdb) x/4a $pl3_ssp 0x4feff0:=C2=A0 =C2=A0 =C2=A0 =C2=A00x7ffd62fee957 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x7ffd63647c1c 0x4ff000:=C2=A0 =C2=A0 =C2=A0 =C2=A0Cannot access memory at address 0x4ff00= 0 (gdb) si ... (gdb) si 0x00007ff725817684 in ?? () 1: $pl3_ssp =3D (void *) 0x4feff0 (gdb) x/1i $pc =3D> 0x7ff725817684:=C2=A0 =C2=A0 =C2=A0 call=C2=A0 =C2=A00x7ff725812f1d (gdb) si 0x00007ff725812f1d in ?? () 1: $pl3_ssp =3D (void *) 0x4fefe8 (gdb) x/4a $pl3_ssp 0x4fefe8:=C2=A0 =C2=A0 =C2=A0 =C2=A00x7ff725817689=C2=A0 0x7ffd62fee957 0x4feff8:=C2=A0 =C2=A0 =C2=A0 =C2=A00x7ffd63647c1c =C2=A0 =C2=A0 Cannot access memory at address 0x4ff000 (gdb) x/1i $pc =3D> 0x7ff725812f1d:=C2=A0 =C2=A0 =C2=A0 jmp=C2=A0 =C2=A0 0x7ff725817c30 (gdb) si ... (gdb) si 0x00007ff725817cde in ?? () 1: $pl3_ssp =3D (void *) 0x4fefe8 (gdb) x/1i $pc =3D> 0x7ff725817cde:=C2=A0 =C2=A0 =C2=A0 ret (gdb) si 0x00007ff725817689 in ?? () 1: $pl3_ssp =3D (void *) 0x4feff0 (gdb) x/1i $pc =3D> 0x7ff725817689:=C2=A0 =C2=A0 =C2=A0 add=C2=A0 =C2=A0 $0x28,%rsp (gdb) x/4a $pl3_ssp 0x4feff0:=C2=A0 =C2=A0 =C2=A0 =C2=A00x7ffd62fee957 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x7ffd63647c1c 0x4ff000:=C2=A0 =C2=A0 =C2=A0 =C2=A0Cannot access memory at address 0x4ff00= 0 (gdb) call and ret modify the shadow stack which is pointed to by $pl3_ssp, is th= at how it's supposed to work? I'm unsure, because amd64-shadow-stack-cmds.exp makes it look like $pl3_ssp should change when moving up or down the frames. Is $pl3_ssp maybe supposed to provide Ia32Pl3SspMsr[$frame] instead? How does that work on linux? In any case, I tried modifying $pl3_ssp like it is done in amd64-shadow-stack.exp. (gdb) p $pl3_ssp $10 =3D (void *) 0x4fefe8 (gdb) p $pl3_ssp=3D0x12345678 $11 =3D (void *) 0x12345678 (gdb) ni error return C:/gdb/src/gdb.git/gdb/x86-windows-nat.c:242 was 1660: The thr= ead context could not be updated because this has been restricted for the p= rocess. 0x00007ffd63720574 in ntdll!ZwMapViewOfSection () from C:\WINDOWS\SYSTEM32\= ntdll.dll So windows doesn't allow modifying the shadow stack pointer. (gdb) p $pl3_ssp $14 =3D (void *) 0x4fefe8 (gdb) p ((void**)$pl3_ssp)[0] $15 =3D (void *) 0x7ff725817689 (gdb) p ((void**)$pl3_ssp)[0]=3D0x12345678 Cannot access memory at address 0x4fefe8 And looks like modifying the shadow stack entries is also prohibited. [1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#extende= d-dll-characteristics [2] https://learn.microsoft.com/en-us/cpp/build/reference/cetcompat Hannes