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

[Hannes Domani <ssbssa@yahoo.de>]

 Am Donnerstag, 27. August 2026 um 12:43:04 MESZ hat Joos, Christina <christina.joos@intel.com> Folgendes geschrieben:

> > -----Original Message-----
> > From: Hannes Domani <ssbssa@yahoo.de>
> > Sent: Mittwoch, 26. August 2026 17:20
> > To: gdb-patches@sourceware.org; Joos, Christina <christina.joos@intel.com>
> > Subject: Re: [PATCH v2 7/8] Windows gdb: Implement XState (Intel AVX)
> > support
> >
> >  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.
> 
> I think this is up to you. I usually prefer to have gdb + gdbserver together.
> But this also depends on how complicated/big the patches are, I guess.
> 
> At the state of this patch your general NEWS comment doesn't state any specifics
> about gdb or gdbserver.
> My assumption would be that both is working. However, gdbserver only works with the
> next patch. So, from that perspective it would make sense to merge them.

I now also think it's better to merge them, so I'll do that.


> > > 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?
> 
> You said "So I compiled amd64-shadow-stack.c with msvc and /CETCOMPAT, and tried
> it out with my gdb build." Based on that I assumed it's somehow possible to enable
> shadow stack for a msvc compiled program in windows.

Yes.


> I also inferred that GDB was able to debug such programs and run relevant tests against
> them. That may have been an incorrect assumption on my part, as I'm not very familiar
> with the current state of support in this area. 😊

msvc doesn't create dwarf debug info, so in my tests I was only debugging in
assembly mode.


> After looking into it a bit, my impression is that if support exists at all, it's only partial.
> 
> Could help me to understand the current state of support?  Or is this documented somewhere?

The gcc docu for -fcf-protection [1] says:

Currently the x86 GNU/Linux target provides an implementation based on
Intel Control-flow Enforcement Technology (CET) which works for i686
processor or newer.

[1] https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fcf-protection

I don't think there is any more info than that available.


> > > 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?
> 
> Gdbserver support is only available with the following patch.
> 
> >
> > > 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).
> 
> Just to avoid misunderstandings:
> You compiled 32-bit + 64-bit GDB or the test program (i386-avx.c) is compiled with 32 bit,
> or both and you tested all combinations together?

I tested all combinations that are possible:
- 32-bit gdb with 32-bit tests
- 64-bit gdb with 64-bit tests
- 64-bit gdb with 32-bit tests


Hannes