From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JuWFLZBz02qGMyQAWB0awg (envelope-from ) for ; Sat, 17 Oct 2026 09:09:36 -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=Ap1wczmf; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7DCAB1E050; Sat, 17 Oct 2026 09:09:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED 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 1FBE61E04E for ; Sat, 17 Oct 2026 09:09:34 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D67CA4BA2E1D for ; Sat, 17 Oct 2026 13:09:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D67CA4BA2E1D 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=Ap1wczmf 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 DD7664BA2E11 for ; Sat, 17 Oct 2026 13:09:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD7664BA2E11 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 DD7664BA2E11 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=1792242546; cv=none; b=WB1RtTPVzWSiV+pEp7OTf4Vbbd6ObI5TTX2kRBOhItoyIOk2Anzc6Tdxb73Akxwwup32+DRZf1opD4rmHuVfol7XKP6KNRfpxvPQy9MdrjhcvqBl61vEWQep8XvS9zXk4x2hykkZOTohK9FFCUUUEFcLpbSqBg3/6yApK9XJvSY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1792242546; c=relaxed/simple; bh=bnsQR/3aV8qmgWxQzXkY6XrrzxjOGHCyQHVP/wYooH0=; h=DKIM-Signature:Date:From:To:Message-ID:Subject:MIME-Version; b=wVvoX75lgNxBtEccDTV+9GUCwhpE6TjbQahYSCN29PChFDyFlyejb9KFBiIiSmlBpwrToNNXFIwjEhG13/JFDv090d+c/jglAdcoheN+aBXLYOLXTaBdvAA0ooTRgn5WDYS3htXa1S33GIpp041oE5CB/Bs00bL9o/gmHV61aKE= 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=Ap1wczmf DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DD7664BA2E11 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s2048; t=1792242544; bh=k5CyrhB+UxemRkwJuX8cS7HbeUMTbQskKxhceK3Yims=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=Ap1wczmfMU7OQl3cbb+S4k7GhS1x3WxerbPkH2dslz/IXZI7ZDGn14WT54bjGL3/PYXeTI3yDibcIZjmj0/EwuUvOWf7kF7WxPP3H+vvvu+h3cXKtbIYVD/aFXVAQ1lFfZOBJhusdz5D6PBG3mBBdHt1meZGDJsg4VVfB4Qph8YxmyGGbPK3g9E3Nu4XGKx5aCSjnmUR5s7sR5gfab14jp4/jTnEvSHhToRlwMSEt8zgQr81ZxcUXAUtTJRQjmFS4qbDHiObHXM0XViJpwOBUY9tZVNHnZMtyf887r6rKs8NRgYLbKsEyZat5LOd8YUcZ0HiJQ2itQOl4Dt+DczIYg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1792242544; bh=PqxY0kmbzQem+sl5+E8gDlU4m53NjZwVS7A3ZNgNWbb=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Jre7af34lnxfEAJnRyisE7mxgXOiJPmc3aap3km5HTSM2og7X39riDsMBnSnbvMC11qk/yZou73xC2u3zrfujx85NIl2j99EvbJNtXeyvtKZfvF8ZKK7r1Q07osBHqphbBikIGgGnsrJ/dDEEbgp5JbMA4bVaKdQpQ0lsONHL9Ho05o/6MwJng7C03rLBdfyFqllWeMiWr/CtpdyescSEiOysOGRxgwyk3jHu2ZTHs6ASWlwMp9B0FS/xbi8Kmw7a0mJpxG8RqZnv3c55UQ/ZW7sVz4zodaHkh4I0nCFa34Mi/B6uvQAiLOlF8tO/Bf1IlQ+0ks1HxBxGvTAK5NdfA== X-YMail-OSG: TEKZKxQVM1kHNUXie5wpRLeirJyq7U5e3rZ.J5hWnNzofcgDQ68EdxjHbRlIjxa Fqel3.dw2TlnrVTHvXOG0.FksOy_nxDkap2nogDA2ckVOWz0zlwFHk4C8TMzxBxreWDifs4EDL_5 o197zpuHbUkCxNerKTauVHZpXLaYoKpkmKgmqNkpzWVv_bpRscZwiWYhqYjgbCeE_VCwoYKOLZIa H1oTfoxHtIxs18q.yAhsFi9OedhA5CmLx4zR5VggD79RMmT9M76RXvsy06shHyUqAhPIanEVZdoX TYWHcl7vq875MUWumnATF.ReSFl9J6eQDZXdA70hpYlIfenjM6N9CFyKGn9Aho5hKMe4E5T1EaY6 EurJYH0.T08_WD1dtwIczlXMEGvurhoLAFUSlTdYE2L60aoh1L2DxImNcdILkJPwQyADxjWXZpJ8 SiYghYcq1tnQPUNGPzs5N6cjMSA.jrRgFmXL.jVvmPEnXCwYrnk.v9sXEw3QULoM6iUv8kBLbw.e D2y8d97osD9ZN7rDOccrdDX8jBTTDMZVany0PZEi0IZLe3W_RKE.1KKc6uYGH27zWZ3seTZQfDnv tq1nMxIgePCDCibVl9bpP1uzwUznx.RJSL9pPvp6KsueadKCQaYO8uZqcdt.ibDbvYBbj2tk6gcb L9bBqIzYGmIM1DOFrTZ_p.aTLdEnxiuWPO3DAO2.jpx5M7LE2jCQRLkzWRQiQtO0ZcgwDJzhCzw. IyL_YZFQF3eQWDyTeZQXORnE80RX8uz_GFREcld8J8scMs6XyR9SWgn7luzySqkUt2YPqPfHjg1G 0cVZpOUqDrqiOE81L6VlHT3TCOIcnSHw4MRDteYEyKw.ppW79rbapitEUquVEy783RTJp_P3co9o ZL.XNJ5D5Rg3JvNGW_tWMW0HsCbSnIfcoj1Ov7fk7OF7w.yKrrN_oE8cIVZWaVHgwugb_4semnVw 7siv_bEs0QW4GDNGAnfZPnAyGAbeKsoBhqoETCYF6ad0pFtvEhfdK56GIfrTRqifX1.n_252w19C aT8ZUqb05Ums_nnKDLDKeNbnaeYFkQzyhIQlkYRoU2ZXKcWyMkhuPv9GgA2xyckL9rhDI8L4OdOZ pmNuHv0VEvkDO_b8KjzWRoRtsavoSdlKu8FpKn7UtkTYWoVynp2tgu3Lyr_0lLrFzAOnz50hBdEj c.JOimQama9ufrFspDh0sDveNaLITrET_WGDr46cLplogXlILEgcxG_ewnoSeW.7pZUVE8zwKNy_ eLP0pp7tKhklSwkyYaCLTtTvUu2JHapJZQAeq_hahAKvzevH3OR68B0BzVy3QOzJpL29l.8UZJYD gxx138Q67GeCoqWlfd6B441ZcAgiRDFFF_hqUXSOelhWKDGbnjPwp6.FciqQxFBu5jfxdA1_Grmk UBYK1RUb9PV.eso.Kxq8Hmo2SGZzKLoQIVgb2pwiCtJOce.KeXVziKduY.pZpZlwTwY1po5z38Vs yLnY7005Lruc2niHgzCbRRzzctWdLw6MEK1a71YnIwIA7d.9HUoGz_kmoLxkBzzlaTVhCUhB7fnq 2K.vJQj2NewqLCC2Jly1XOrzGqgSplT5zO6CZ7ujQiSCYM2Zvtpq1vYEBbpCwl.nIbAtIRRtJbse MZgl8m5NTqylr1sNVi_62DwdYocyN8emXiT.ip9kFvAXD4Un3K3XlpztvbrqQWlWCMXct6MDLOh8 x5G4zU2j_neIJK6XZYSqe.tI9Shrburn7Uwo677aP1CgW7_Wfhhq3pJb7G0hvFypHlf2KSjRVWr8 H3r3SNIVGs3O11nLgWRhlpo7qh9ZdnigNFKldFHpGkT5Q6mmIGZK9V3P5cGpvjtR9kd5PSh_bfjo R2Si7YqUwPU4P_ZiUZ6wo1HAogfOEFNHqDsKB69xMI2PZBk5YJph4DKNYG738vlwNWK5abewScPI nojLQoo2H35.Ntbq1hTGafjSWmh84SCOxdhe0QoJXLmRTgBlPDs_R6vX_SL_01AVQ0j25eY2oorr W1i92T6ADQsOPhUVrmnfZhVRWDW7oUY7UsYw7Q7ESpcIjDyrMeBJLqlo_WyyI2fYmxHa7IiASbRc sDmUDnw-- X-Sonic-MF: X-Sonic-ID: b9862a6e-d63c-48c4-aa15-7b7be74a3d16 Received: from sonic.gate.mail.ne1.yahoo.com by mail-asdoutdeli-p-cin-euwe4-prod-sonicconsumer-svc-102 with HTTP; Sat, 17 Oct 2026 13:09:04 +0000 Date: Sat, 17 Oct 2026 13:09:00 +0000 (UTC) From: Hannes Domani To: Tom Tromey , "Joos, Christina" Cc: "gdb-patches@sourceware.org" Message-ID: <1527641773.225360.1792242540860@mail.yahoo.com> In-Reply-To: References: <20260829145823.1034821-1-ssbssa@yahoo.de> <20260829145823.1034821-7-ssbssa@yahoo.de> <87v78o6exm.fsf@tromey.com> <1296838558.27687.1788285654283@mail.yahoo.com> Subject: Re: [PATCH v3 7/8] Windows gdb: Implement AVX register support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: WebService/1.1.26740 YMailCLDNovation 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 Mittwoch, 14. Oktober 2026 um 15:00:41 MESZ hat Joos, Christina Folgendes geschrieben: > > -----Original Message----- > > From: Joos, Christina > > Sent: Dienstag, 8. September 2026 17:28 > > To: 'Hannes Domani' ; Tom Tromey > > Cc: gdb-patches@sourceware.org > > Subject: RE: [PATCH v3 7/8] Windows gdb: Implement AVX register support > > > > > -----Original Message----- > > > From: Hannes Domani > > > Sent: Dienstag, 1. September 2026 20:01 > > > To: Tom Tromey > > > Cc: gdb-patches@sourceware.org > > > Subject: Re: [PATCH v3 7/8] Windows gdb: Implement AVX register > > > support > > > > > > Am Dienstag, 1. September 2026 um 19:48:28 MESZ hat Tom Tromey > > > Folgendes geschrieben: > > > > > > > >>>>> "Hannes" == Hannes Domani writes: > > > > > > > > Hannes> This adds support for the Intel AVX registers on Windows. > > > > Hannes> It enables accessing registers $ymm0 - $ymm15 where they are > > > available. > > > > > > > > Hannes> After this patch gdb.arch/i386-avx.exp passes on windows. > > > > > > > > I'd like it if Christina would review this. > > > > > > > > Hannes> @@ -1339,7 +1339,7 @@ initialize_loadable () > > > > Hannes> { > > > > Hannes> /* Available XState features masked with implemented > > > > Hannes>features. */ > > > > Hannes> xstate_features = (GetEnabledXStateFeatures () > > > > Hannes> - & X86_XSTATE_SSE_MASK); > > > > Hannes> + & X86_XSTATE_AVX_MASK); > > > > Hannes> /* The extended XState functions are only needed if > > > > Hannes>the available > > > > Hannes> features exceed SSE. */ > > > > Hannes> if ((xstate_features & ~X86_XSTATE_SSE_MASK) == 0) > > > > > > > > Ok, ignore my earlier message for patch 6. I see what's going on now. > > > > > > > > I don't have any problem with this patch. I'm not certain I totally > > > > understand it, but that's ok. > > > > > > > > One thing I did see while doing the background reading is that > > > > supposedly the xstate feature flags are vendor-specific. So does > > > > some check of the vendor ID need to be done? I do not know. > > > > > > As I understand it (and I might be wrong about that), there are some > > > vendor- specific XState-bits, but stuff regarding AVX and AVX-512 are > > > the same everywhere. > > > > The MPX state, for instance, is not implemented by AMD (and has been > > removed from GDB in the meantime, since the feature is deprecated). > > For AVX and AVX-512 I can confirm that they are both implemented for AMD > > and Intel. > > For CET I'd need to double check, but we decided to not add it anyways for > > now. > > So using the masks as you do in the 2 patches should be fine. > > > > Due to AMD not implementing MPX, there are some differences in the xsave > > offsets for AMD and Intel CPUs, see the dedicated handling here: > > - gdb/i387-tdep.c:i387_guess_xsave_layout: This is relevant for corefiles only. > > - gdb/i386-tdep.c: i387_fallback_xsave_layout > > > > Both functions are called at some point from i386_gdbarch_init. > > > > I believe for live targets, since you don't hard-code the offsets in your patch > > series but get them using LocateXStateFeature in the end, it should be safe. > > > > However, we still call i386_gdbarch_init for windows, too. > > So tdep->xsave_layout should still be available but is not consumed or > > configured. > > This it at least what I observed when doing some basic debugging in windows, > > which I just started today. > > At my current level of understanding, I don't think it makes sense to use it for > > Windows. > > > > Reading > > "The LocateXStateFeature function must be used to find an individual XState > > feature within an extensible CONTEXT structure. Features are not necessarily > > contiguous in memory and applications should not assume the offset between > > two consecutive features will remain constant in the future." > > https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase- > > locatexstatefeature confirms that I think. > > > > Hi Hannes, > > I believe that this thread might be the right starting point to discuss the per-register locate_xstate_feature calls in get_context_reg_ptr, since it describes the background and documentation of this topic a bit. > > You said > "I was also thinking that these look-ups are not ideal. > As I understand it, the offsets for each feature are not fixed values on windows, but they should be the same for all threads on a system. > In that case, maybe we could calculate these offsets for all registers once, put them in a vector, and use that in get_context_reg_ptr? > I'm also assuming that the register numbers always stay the same. > I'm just not sure at which point the offset calculation should be done. > Any suggestions?" > > I believe you are right for the fixed offset for all threads on a system, but this is not clear from the official documentation in windows, or did I miss anything here ? Due to that I am not sure if we can assume that. I'm not sure about than any more either, because copilot tells me a system could have CPUs with different capabilities, and threads running on a CPU with less xstate features would then have different feature offsets. But it also tells me that calling GetEnabledXStateFeatures() would give me different results depending on which thread it was called on, and basically making it useless for these kind of systems, at least for debuggers. So I still believe the feature offsets are always the same, but I can not prove or test this in any way. > On linux, we don't have those per-register function calls to fetch the registers, so we also don't have the per-register find_regno calls on gdbserver side. If we would have one function call for the xsave registers, it would shrink the number of locate_xstate_feature calls, too. But this is probably a bigger refactoring. You mean you don't have those per-register function calls on linux for gdbserver, right? Because I just debugged gdb, and when I do something like 'p $zmm0', the register contents are retrieved by amd64_linux_nat_target::fetch_registers, which then calls amd64_supply_xsave. But amd64_supply_xsave is called with regnum=-1, so all xstate registered are fetched, so the next "p $zmm1" doesn't have to do the ptrace(PTRACE_GETREGSET) call any more. > So, from my perspective, the safest approach would be either to do the refactoring as described above, or to accept those repeated locate_xstate_feature calls. > > What do you think? I'm not completely sure how the refactoring should look like. Do you mean similar to the amd64_supply_xsave call I just mentioned? Would that work for gdbserver as well? What about store_registers? Hannes