RE: [PATCH 5/8] Windows gdb: Prepare XState functions

> -----Original Message-----
> From: Hannes Domani <[email protected]>
> Sent: Freitag, 17. Juli 2026 17:07
> To: [email protected]; Schimpe, Christina
> <[email protected]>
> Subject: Re: [PATCH 5/8] Windows gdb: Prepare XState functions
> 
>  Am Freitag, 17. Juli 2026 um 17:04:51 MESZ hat Hannes Domani
> <[email protected]> Folgendes geschrieben:
> 
> > Am Freitag, 17. Juli 2026 um 16:41:54 MESZ hat Schimpe, Christina
> <[email protected]> Folgendes geschrieben:
> >
> > > > -----Original Message-----
> > > > From: Hannes Domani <[email protected]>
> > > > Sent: Sonntag, 12. Juli 2026 13:32
> > > > To: [email protected]
> > > > Subject: [PATCH 5/8] Windows gdb: Prepare XState functions
> > > >
> > > > These functions will then be used to access the XState registers.
> > > > ---
> > > >  gdb/nat/windows-nat.c |  31 +++++++++++  gdb/nat/windows-nat.h |
> > > >116
> > > > ++++++++++++++++++++++++++++++++++++++++++
> > >
> > > For this and the following patch:  I can see that you introduced x86
> > > specific code, but used the generic windows-nat.c/.h files for it.
> > > In gdb linux code we try to keep arch specific details in separate files.
> > >
> > > In an earlier patch you tried to keep it separate for windows, too:
> > > "Move x86 register code into x86-windows-nat.c ".
> > >
> > > I am not familiar with windows specific code, but do you think
> > > moving this to an arch specific file (for instance gdb/x86-windows-nat.c) is
> an option?
> >
> > Yes, I tried keeping them separate, but these functions are also used
> > by gdbserver, so they have to be in a nat/ header, which makes this a
> > bit more complicated.

Ok, I understand.

> > But I recently found out that Windows apparently also provides SVE
> > registers for ARM64 with these same XState functions [1], so if we
> > plan to support that, we would probably just move them back here
> anyways.
> 
> Of course I had to forget to include the link...
> 
> [1] https://github.com/llvm/llvm-project/pull/205906

Hm, I am a bit confused about the windows interfaces. If they are meant to be
architecture independent it seems that this and the following patch are almost
arch independent, too. Except for these lines and their corresponding include:

~~~
      /* Available XState features masked with implemented features.  */
      xstate_features = GetEnabledXStateFeatures ()
	& (X86_XSTATE_AVX_AVX512_PKU_MASK | X86_XSTATE_CET_U);
      /* The extended XState functions are only needed if the available
	 features exceed SSE.  */
      if ((xstate_features & ~X86_XSTATE_SSE_MASK) == 0)
	xstate_features = 0;
~~~

In any case, maybe someone else with a bit more windows background has
another opinion on this, too.

Christina