From: "Joos, Christina" <christina.joos@intel.com>
To: Hannes Domani <ssbssa@yahoo.de>, Tom Tromey <tom@tromey.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v3 7/8] Windows gdb: Implement AVX register support
Date: Tue, 8 Sep 2026 15:27:32 +0000 [thread overview]
Message-ID: <SN7PR11MB7638D2AF2501CE5340C5405889B12@SN7PR11MB7638.namprd11.prod.outlook.com> (raw)
In-Reply-To: <1296838558.27687.1788285654283@mail.yahoo.com>
> -----Original Message-----
> From: Hannes Domani <ssbssa@yahoo.de>
> Sent: Dienstag, 1. September 2026 20:01
> To: Tom Tromey <tom@tromey.com>
> 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
> <tom@tromey.com> Folgendes geschrieben:
>
> > >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> 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 the
> > Hannes>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.
Corefiles:
I started some basis testing in windows and checked out my own patch series
https://sourceware.org/pipermail/gdb-patches/2026-September/230051.html
which extends avx and avx512 testing for corefiles together with your patches.
I see UNSUPPORTED for those new corefile tests and other existing corefile tests in gdb return similar results. So I believe this is ok for windows.
If you have any concerns with those test extensions (or my reasoning above), I'd be glad if you'd let me now.
I will provide some feedback on the entire patch in a separate email.
Christina
________________________________________
Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 (89) 99143-0
www.intel.de
Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman
Chairperson of the Supervisory Board: Sonja Pierer
Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
next prev parent reply other threads:[~2026-09-08 15:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260829145823.1034821-1-ssbssa.ref@yahoo.de>
2026-08-29 14:48 ` [PATCH v3 1/8] gdb/testsuite: Add Windows replacement for aligned_alloc Hannes Domani
2026-08-29 14:48 ` [PATCH v3 2/8] Windows gdb: Use allocated buffer for CONTEXT Hannes Domani
2026-09-01 17:22 ` Tom Tromey
2026-09-01 17:30 ` Hannes Domani
2026-08-29 14:49 ` [PATCH v3 3/8] Windows gdb: Remove mappings member from windows_per_inferior Hannes Domani
2026-08-29 14:49 ` [PATCH v3 4/8] Windows gdb: Refactor getting pointer to register inside context Hannes Domani
2026-08-29 14:49 ` [PATCH v3 5/8] Windows gdb: Prepare XState functions Hannes Domani
2026-08-29 14:49 ` [PATCH v3 6/8] Windows gdb: Get available XState features Hannes Domani
2026-09-01 17:38 ` Tom Tromey
2026-09-01 17:44 ` Hannes Domani
2026-09-01 17:51 ` Tom Tromey
2026-08-29 14:49 ` [PATCH v3 7/8] Windows gdb: Implement AVX register support Hannes Domani
2026-09-01 17:48 ` Tom Tromey
2026-09-01 18:00 ` Hannes Domani
2026-09-08 15:27 ` Joos, Christina [this message]
2026-09-04 16:33 ` Joos, Christina
2026-09-08 13:04 ` Rohr, Stephan
2026-09-10 11:33 ` Joos, Christina
2026-08-29 14:49 ` [PATCH v3 8/8] Windows gdb: Implement AVX-512 " Hannes Domani
2026-08-29 15:40 ` Eli Zaretskii
2026-09-01 17:49 ` Tom Tromey
2026-09-08 13:05 ` Rohr, Stephan
2026-09-10 12:08 ` Joos, Christina
2026-09-10 14:39 ` Hannes Domani
2026-09-13 21:18 ` Joos, Christina
2026-09-10 16:54 ` Hannes Domani
2026-09-13 21:37 ` Joos, Christina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=SN7PR11MB7638D2AF2501CE5340C5405889B12@SN7PR11MB7638.namprd11.prod.outlook.com \
--to=christina.joos@intel.com \
--cc=gdb-patches@sourceware.org \
--cc=ssbssa@yahoo.de \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox