From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id QWa1DeRHkGqNfwYAWB0awg (envelope-from ) for ; Thu, 27 Aug 2026 10:21:24 -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=DaLYaeg1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 214C81E0A3; Thu, 27 Aug 2026 10:21:24 -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 [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 979AE1E033 for ; Thu, 27 Aug 2026 10:21:21 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6CEB24BA23DE for ; Thu, 27 Aug 2026 14:21:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6CEB24BA23DE 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=DaLYaeg1 Received: from sonic.asd.mail.yahoo.com (sonic-euwe4-0022.asd.mail.yahoo.com [34.2.86.21]) by sourceware.org (Postfix) with ESMTPS id 6CAE84BA7997 for ; Thu, 27 Aug 2026 14:20:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6CAE84BA7997 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 6CAE84BA7997 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=34.2.86.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787840442; cv=none; b=ty8aNOK6Q4yPIGFjt52qaMPJ6hjb3cyaOuCK555YH0poynvkpeBgVuLbDZgWc9WrB8Hd3nd2oZevEeeAuivdI4imp2/Sngx/HGnvWQ33wm0iIMJtqZg5jhdaSt/8R9HfaQxOJ7E07X9ySIC5fjqsyDrMtHGd8D0dqGQWllhLMCM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787840442; c=relaxed/simple; bh=cNFdJ1Zc06ry4ao0E80J0Hyf22f8UrO/IBDG4huK4YU=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=Ox3icHdFFPsPYNlpmZhXR2JdTA1wSQzcF5qMo6/GS+310amAUGFTql0xbQSRlCp4hTSeQ2f82RHHNeo+ka7c7IcCvXTXlvFNdostCcrCRCi+ySeAt8+/x/3nPDZOOBiWzlqHD2M6aZL1m6IrJjFsguKGmke94/yq5MdGcOwP8WA= 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=DaLYaeg1 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6CAE84BA7997 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1787840441; bh=cNFdJ1Zc06ry4ao0E80J0Hyf22f8UrO/IBDG4huK4YU=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=DaLYaeg1SY6bPb13GTYgFFp5vquUpn09frBPr3GsLRDOPBAwXPyMF/OR41rKUUwoSLpkzNCLqQ52vXMzH4aggwpXOgIuXbWxW+d20jZyT1oO0vpxYq1AbCb7c13TJG7OkUzcKH5UDq5lw1jvrhb2xz/uljQpK+84Y41drXFg2bwg0cLGZm3SGFyYehsyTKIM9UuuKjh/Va4KS2Bu4yHD/Std/tgUAnAW1tVFqSdwzS0XAm1Ms7W4UqHlKPdU11v4Gcfr2qivI5KrdBKzrO4xYryzZ3F9jKo8OGf1zj0kPC8b8OxG/RadAfrG5hCXvzKEEsVZMpRmro8692J+DmuTeA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1787840441; bh=iEUH8MAQrZxX6LepnAMtXje7tczJMOxiN6yMTBX2ZWZ=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=k+cJhiyJss/qCnfEv1BGnHO8h7/ZoJFVsO5zkriANahuVri0ckCJd9oEXemuYbugkSuhd9ZQkaYcEM+rrj2b+bhnkqrgJsB4xgDxuyXtIIhNU0zQYAGvit6rRDzLcA47KZe+1Lsn1uMC+T5RoKOFCWsIYp8C+Kkp/+WiyV6oZetWn4OC+3/DAH7Bn9rKJNWXDslHKilL8sGA06kvkrG+ftj3LDS5PD2jM2GZUJ8CSfQHPy9bYq0oqqimlLW+daLUnAHSES+Nv63H4a9PdcRzYdd6WYC+L3kTnkVTlRB1PyFrtH1o+RQNFr4mkdJt+0qvKDezmt5BwxI+V9gD2/7mjw== X-YMail-OSG: GMSAbKQVM1lkI2WT31WHWwVM6bAniwRtHggE6wCeEVJA8upKEqwKhRmNxEnTxSG gjUryQYjkM1A81_k7.x00i2iErHsd1.vMwMwsJfHqfEIGdtmI52GbKNGxF8bvv4KAu9iEiMOcvY8 cKyaOl_oP8_tay7imcHwTcC_J6OrKWEtPbAEOUdxH.BN_5_kPOc5IWR2lmtWLJASQSRzsy4u.AO6 n64txmoPDOu8LuIWqx4_d5N_ysZq9rOdCJoGepW2oXTYftrq.e1Oss4czn5S_soQbOUc0.t9LETN pePsmCoRHx6ztgMZiR_8Tt7pJBjbrAkKFfwBZ0Jwok6mHsSfZ0zuko_EV319reBudhJUCkY7zXqc OvE817zEam9LGOcVfXTzXzWjtOJSVuyI2hMgkkPkmjZxZRDsUWk8230U15GpniCmlTGnuJKL.Ogv B.gxYbiCNC7mrcINbnI3a.sp7hWNHpZRka.pNVr8BVXAymPW2rBAAX0XGUUrYPZJuXbpUXj1zn9H pJoMhzXt.pWZD0qv2fahrYKO5I_EfL4mJOxS51gAZml5.q8HutdtATcz6mnl1nrs4a7w3zFaUWhF ts16A89jL2TGNP6Mv_AGdPd9ohh4e0aKWtlajGDm1CQmUV2EmILbty9OqZSIIjDcg1xxYBn3WUtW FneGYTxEHCr4AKVRcRkEbLytwUj5nO1XKKtLqa5GVUz4WKWpKrcMHFLzv2lFd7FrEOar0Ne7HcHG iYCNf21v_CoUqP_Y549aa58tpXVaqMuTDvMUGuyOmN8lQ8NXIyqXh2kMR8rkPlABW4LTpUZWibCn EbLuMUfu7.iNjVsnvRZNyI8NvtXfFRxjzZYoIejfUlI6HE.YBYxP7jJn6HVkkN.EHjj1u4P3KG.H L99IchyOOxAVUF11EJaPkS2MKUgA8aui4aghnDI0OIjLxjSVeSYRjpTAwfiWYDbyh4sJMPCclynl 2cLq0Y5YQwHTL1d5OB_SoRv3JeRX1dO039hOI4gT3hQY8240jdlIlDvKv7czlDOLDhy.cGpYyL1i pXZ3IetVgxlN_m.Fc0ZZvy.jG9Gx1Dpw7Aps6MvMYxv8JPVwYSxXobCVm8.GAz4X2CC3hO9rLR0b 5pwK4CvWZ68bRLZX0aeVufarw0CZ.q8wTMR106I0mtBKRQWPi.LgAmVmEAlBI63ZdFesqSBeuw14 EjQt1U36OiUR56U6zlsVgxRIzD1qW86KoA1CaQlAjEs6QsCefdstGHjKgE7oApiO_QOh16Jcc0.0 7eRTJIGE6pRUzsNg8DLxc7FsV4YqfdxVLDkUcmvYjoo_dt1lg7YbLWNycd8eV0SWBVspv4xKhoqO 7XfQxycFzI09UDEZt1XveHSzb2LuC7B.4wujsLITc4H9yq3su8oDjWnWwx3LZfhTSbWK27GHTCOx ScwxXq8Rw0cnWLegbHHufsgcoRqBOhxUWqsY9regn3CfuC9GjCuweQ81wKf2QICfdmQjAQBbbZ99 onovYEvh1udzHv8tW7R7vUmpu.rLPcZvBS1cc.Jgs0mnIkv2vbHvXCekVcX.8XnCQfmgzUNr4bXE 0THsz9.qSZhQTBjzjRPbJz1TdHbcs7Y5e2Ck6nR36CelV3xseVZZ8key9ICnXJgpCDRFXn0ZkQNP F1gTzkaCFCDqZ3JjyMxu.EepsxMUJwwPB8PvdyG_cMds6Pe8D2vYb.ZlI_PhyDrJKQAD_Uhp.UWo mNfrDYnsk.B5RSRcN0AS6L3Tbf2FNfQnp2RtWJEZ6KCcnSl2uhpyfMoZt5onD9R3zv.QBCjPqho. el56B_LLtemuOzmBvPp647vvt1mQcDRvkHl5Qkdtgli8QZL3URwZ5R5oh5b7g.Y09mN9qemcynRc J5djPBUSbj8_dCWIystvorM1jAccDCcO45bDoWoMF.XIuzQ4.u4I0cMTekxUcLvlcb3CFtIKml9w TUekGtt_1E6ixuEXFS4RdWWD.glCY3JTXGUHAPT0oqcwtM9opCoFAkP0XP8cZiNkyaW.5a4JUlg1 5DAQffKT3.hEL6C.x9Mk1dzpu9RaKHmO79MN_T_7jQdvE9Y4syT_uNempOyHViFNkll8NkSjIsF_ tYjfplV_Gm66igIXVnXDyaE0- X-Sonic-MF: X-Sonic-ID: caf7cf57-36ec-4e0a-8d55-c563eb509caa Received: from sonic.gate.mail.ne1.yahoo.com by mail-asdoutdeli-p-cin-euwe4-prod-sonicconsumer-svc-101 with HTTP; Thu, 27 Aug 2026 14:20:41 +0000 Date: Thu, 27 Aug 2026 14:20:39 +0000 (UTC) From: Hannes Domani To: "gdb-patches@sourceware.org" , "Joos, Christina" Message-ID: <2092195315.719675.1787840439209@mail.yahoo.com> In-Reply-To: References: <20260727174619.1089041-1-ssbssa@yahoo.de> <20260727174619.1089041-7-ssbssa@yahoo.de> <1041475645.327467.1787757617271@mail.yahoo.com> Subject: Re: [PATCH v2 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.26380 YMailCLDNorrin 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 Donnerstag, 27. August 2026 um 12:43:04 MESZ hat Joos, Christina Folgendes geschrieben: > > -----Original Message----- > > From: Hannes Domani > > Sent: Mittwoch, 26. August 2026 17:20 > > To: gdb-patches@sourceware.org; Joos, Christina > > Subject: Re: [PATCH v2 7/8] Windows gdb: Implement XState (Intel AVX) > > support > > > >=C2=A0 Am Mittwoch, 26. August 2026 um 16:28:41 MESZ hat Joos, Christina > > Folgendes geschrieben: > > > > > Hi Hannes, > > > > > > Thanks a lot for working on this. > > > > > > I did not find the time to try this out on windows myself, since I wa= s not able > > to work last week. > > > This is my code-based review for now. > > > > > > > -----Original Message----- > > > > From: Hannes Domani > > > > Sent: Montag, 27. Juli 2026 19:43 > > > > To: gdb-patches@sourceware.org > > > > Subject: [PATCH v2 7/8] Windows gdb: Implement XState (Intel AVX) > > > > support > > > > > > The commit message header still seems somewhat misleading, as it > > > references only Intel AVX, while the commit also includes changes rel= ated to > > AVX-512 and shadow stack. > > > > > > I think it would be helpful if we'd adapt the commit message header o= f > > > this patch to include AVX-512, too. > > > > > > For shadow stack I think it would make sense to move this to a > > > separate commit and give more details on the tests that are passing/ > > > not passing and the limitations we have in windows for shadow stack e= nabled > > programs. > > > > I agree, at least shadow stack should be its own commit. > > > > And I wonder if, instead of splitting up into gdb/gdbserver as it is no= w, maybe I > > should merge them, and split them again into AVX/AVX-512/shadow-stack. >=C2=A0 > I think this is up to you. I usually prefer to have gdb + gdbserver toget= her. > But this also depends on how complicated/big the patches are, I guess. >=C2=A0 > At the state of this patch your general NEWS comment doesn't state any sp= ecifics > about gdb or gdbserver. > My assumption would be that both is working. However, gdbserver only work= s with the > next patch. So, from that perspective it would make sense to merge them. I now also think it's better to merge them, so I'll do that. > > > Besides reading or writing the shadow stack pointer for linux we had > > > to enable > > > - displaced stepping > > > - the return command > > > - inferior calls > > > for shadow stack enabled programs, which are all covered by current s= hadow > > stack tests. > > > > > > Based on what you said > > > > > > ~~~ > > > 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 t= o 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 trie= d > > it out with my gdb build. > > > Before I always got $pl3_ssp=3D0, and with this new exe I always get > > $pl3_ssp=3D1. > > > ~~~ > > > I assume you cannot execute those tests. Can you confirm? > > > > > > Would it make sense to add dedicated tests for windows shadow stack > > > (in the shadow-stack specific patch), based on the current enablement= you > > describe above ? > > > > > > Or, maybe even better, can you adapt the proc allow_ssp_tests for win= dow > > support? > > > You said: > > > " It turns out binutils/gcc really don't support this on windows yet.= " > > > Could you add a fix to make this work for windows using msvc and > > /CETCOMPAT ? > > > > I'm not sure what you mean here. > > Instead of the binutils linker, use the one from msvc? >=C2=A0 > You said "So I compiled amd64-shadow-stack.c with msvc and /CETCOMPAT, an= d tried > it out with my gdb build." Based on that I assumed it's somehow possible = to enable > shadow stack for a msvc compiled program in windows. Yes. > I also inferred that GDB was able to debug such programs and run relevant= tests against > them. That may have been an incorrect assumption on my part, as I'm not v= ery familiar > with the current state of support in this area. =F0=9F=98=8A msvc doesn't create dwarf debug info, so in my tests I was only debugging i= n assembly mode. > After looking into it a bit, my impression is that if support exists at a= ll, it's only partial. >=C2=A0 > Could help me to understand the current state of support?=C2=A0 Or is thi= s documented somewhere? The gcc docu for -fcf-protection [1] says: Currently the x86 GNU/Linux target provides an implementation based on Intel Control-flow Enforcement Technology (CET) which works for i686 processor or newer. [1] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-f= cf-protection I don't think there is any more info than that available. > > > In any case, all this information should be part of the commit messag= e. > > > > > > I also wonder if we should provide some feedback to the user when he > > > attempts to write the shadow stack pointer. > > > > > > Currently we see this, right? > > > > > > ~~~ > > > (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: T= he > > thread context could not be updated because this has been restricted fo= r the > > process. > > > 0x00007ffd63720574 in ntdll!ZwMapViewOfSection () from > > > C:\WINDOWS\SYSTEM32\ntdll.dll ~~~ > > > > > > I am not GDB windows expert, so I am not sure if that is useful infor= mation > > for the user. > > > Whatever we display when attempting to write the register, I think it > > > would make sense to document this somehow. At least in the commits > > > message + even better we could add a test for this. > > > > To be honest, the shadow stack stuff is not that important to me. > > And since binutils/gcc currently can't create executables with this ena= bled, > > maybe it's not worth it including it at this time. > > I only added it because windows suddenly provided this register info, p= robably > > after some update. > > > > > > > > This adds support for the Intel AVX and AVX-512 registers on Window= s. > > > > It enables accessing registers $ymm0 - $ymm31, $zmm0 - $zmm31, and > > > > $k0 - $k7 where they are available. > > > > > > > > It also enables reading the shadow stack pointer register $pl3_ssp > > > > (for executables marked compatible with CET shadow stack [1]), but > > > > modifying it seems to be restricted restricted by windows. > > > > > > Nit: duplicate restricted > > > > > > > > > > > After this patch the tests gdb.arch/i386-avx.exp and > > > > gdb.arch/i386-avx512.exp pass on windows. > > > > > > Nit: let's add for on windows for Unix boardfile, or something like t= hat. > > > So it's clear that gdbserver support is missing. > > > > What gdbserver support is missing? >=C2=A0 > Gdbserver support is only available with the following patch. >=C2=A0 > > > > > Did you run the tests for 32 bit, too ? > > > > Yes, the same tests succeed for 32 bit as well (with both 32 and 64 bit= gdb). >=C2=A0 > Just to avoid misunderstandings: > You compiled 32-bit + 64-bit GDB or the test program (i386-avx.c) is comp= iled with 32 bit, > or both and you tested all combinations together? I tested all combinations that are possible: - 32-bit gdb with 32-bit tests - 64-bit gdb with 64-bit tests - 64-bit gdb with 32-bit tests Hannes