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

["Joos, Christina" <christina.joos@intel.com>]

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

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

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

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?

> > 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?

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.