Re: [PATCH v2 7/8] Windows gdb: Implement XState (Intel AVX) support

[Hannes Domani <ssbssa@yahoo.de>]

 Am Mittwoch, 26. August 2026 um 16:28:41 MESZ hat Joos, Christina <christina.joos@intel.com> 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 was not able to work last week.
> This is my code-based review for now.
> 
> > -----Original Message-----
> > From: Hannes Domani <ssbssa@yahoo.de>
> > 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 related to AVX-512 and shadow stack.
> 
> I think it would be helpful if we'd adapt the commit message header of 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 enabled 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 now,
maybe I should merge them, and split them again into AVX/AVX-512/shadow-stack.


> 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 shadow 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 to 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 tried it out with my gdb build.
> Before I always got $pl3_ssp=0, and with this new exe I always get $pl3_ssp=1.
> ~~~
> 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 window 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?


> In any case, all this information should be part of the commit message.
> 
> 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=0x12345678
> $11 = (void *) 0x12345678
> (gdb) ni
> error return C:/gdb/src/gdb.git/gdb/x86-windows-nat.c:242 was 1660: The thread context could not be updated because this has been restricted for 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 information 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
enabled, maybe it's not worth it including it at this time.
I only added it because windows suddenly provided this register info,
probably after some update.


> > This adds support for the Intel AVX and AVX-512 registers on Windows.
> > 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 that.
> So it's clear that gdbserver support is missing.

What gdbserver support is missing?


> 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).


Hannes