Re: [PATCH v3 7/8] Windows gdb: Implement AVX register support

[Hannes Domani <ssbssa@yahoo.de>]

 Am Mittwoch, 14. Oktober 2026 um 15:00:41 MESZ hat Joos, Christina <christina.joos@intel.com> Folgendes geschrieben:

> > -----Original Message-----
> > From: Joos, Christina
> > Sent: Dienstag, 8. September 2026 17:28
> > To: 'Hannes Domani' <ssbssa@yahoo.de>; Tom Tromey <tom@tromey.com>
> > Cc: gdb-patches@sourceware.org
> > Subject: RE: [PATCH v3 7/8] Windows gdb: Implement AVX register support
> >
> > > -----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
> > > > 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