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: Donnerstag, 27. August 2026 16:21
> 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 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.

Yes, this is what I expected. Can we run tests in the gdb testsuite with msvc?

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

I rather meant GDB support for msvc compiled programs.

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

Ok, sounds good.

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