RE: [PATCH 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, 30. Juli 2026 17:41
> To: gdb-patches@sourceware.org; Joos, Christina <christina.joos@intel.com>
> Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel AVX) support
> 
>  Am Donnerstag, 30. Juli 2026 um 10:20:53 MESZ hat Joos, Christina
> <christina.joos@intel.com> Folgendes geschrieben:
> 
> > > -----Original Message-----
> > > From: Hannes Domani <ssbssa@yahoo.de>
> > > Sent: Samstag, 18. Juli 2026 18:07
> > > To: gdb-patches@sourceware.org; Schimpe, Christina
> > > <christina.schimpe@intel.com>
> > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel AVX)
> > > support
> > >
> > >  Am Freitag, 17. Juli 2026 um 21:06:16 MESZ hat Schimpe, Christina
> > ><christina.schimpe@intel.com> Folgendes geschrieben:
> > >
> > > > > -----Original Message-----
> > > > > From: Hannes Domani <ssbssa@yahoo.de>
> > > > > Sent: Freitag, 17. Juli 2026 18:27
> > > > > To: gdb-patches@sourceware.org; Schimpe, Christina
> > > > > <christina.schimpe@intel.com>
> > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState (Intel
> > > > > AVX) support
> > > > >
> > > > >  Am Freitag, 17. Juli 2026 um 17:26:14 MESZ hat Schimpe,
> > > > >Christina <christina.schimpe@intel.com> Folgendes geschrieben:
> > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Hannes Domani <ssbssa@yahoo.de>
> > > > > > > Sent: Freitag, 17. Juli 2026 16:50
> > > > > > > To: gdb-patches@sourceware.org; Schimpe, Christina
> > > > > > > <christina.schimpe@intel.com>
> > > > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState
> > > > > > > (Intel
> > > > > > > AVX) support
> > > > > > >
> > > > > > >  Am Freitag, 17. Juli 2026 um 16:16:31 MESZ hat Schimpe,
> > > > > > >Christina <christina.schimpe@intel.com> Folgendes geschrieben:
> > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Hannes Domani <ssbssa@yahoo.de>
> > > > > > > > > Sent: Freitag, 17. Juli 2026 15:47
> > > > > > > > > To: gdb-patches@sourceware.org; Schimpe, Christina
> > > > > > > > > <christina.schimpe@intel.com>
> > > > > > > > > Subject: Re: [PATCH 7/8] Windows gdb: Implement XState
> > > > > > > > > (Intel
> > > > > > > > > AVX) support
> > > > > > > > >
> > > > > > > > >  Am Freitag, 17. Juli 2026 um 14:54:59 MESZ hat Schimpe,
> > > > > > > > >Christina <christina.schimpe@intel.com> Folgendes geschrieben:
> > > > > > > > >
> > > > > > > > > > Hi Hannes,
> > > > > > > > > >
> > > > > > > > > > Thank you for working on this.
> > > > > > > > > > It appears that this patch uses the same commit
> > > > > > > > > > message header as patch #8. Is it intentional that
> > > > > > > > > > these are separate
> > > commits?
> > > > > > > > >
> > > > > > > > > This one is the gdb part, and #8 is the gdbserver part,
> > > > > > > > > that is stated in the title.
> > > > > > > >
> > > > > > > > Oups, I wonder how I came to that conclusion.  Sorry for that.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > In any case, IMO, commit messages should not have
> > > > > > > > > > identical
> > > headers.
> > > > > > > > > > Also, this patch seems big enough for a commit message
> > > > > > > > > > which is not header only. :)
> > > > > > > >
> > > > > > > > This part still stands for the commit message. Since it's
> > > > > > > > not only avx registers, I believe it makes sense to share more details
> here.
> > > > > > >
> > > > > > > Yes, I will do that.
> > > > > > >
> > > > > > >
> > > > > > > > > > Do any AVX-* specific tests pass on Windows now? If
> > > > > > > > > > so, it would be helpful to mention that in the commit message as
> well.
> > > > > > > > >
> > > > > > > > > I actually planned to add that info, but forgot.
> > > > > > > > >
> > > > > > > > > These tests then pass on Windows:
> > > > > > > > > gdb.arch/i386-avx.exp
> > > > > > > > > gdb.arch/i386-avx512.exp
> > > > > > > >
> > > > > > > > What's the state for SSE  (gdb.arch/i386-sse.exp) ?
> > > > > > >
> > > > > > > i386-sse.exp works since patch #1, it was only a compile
> > > > > > > issue of the test itself.
> > > > > > > I will mention this in the patch as well.
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > >
> > > > > > > > I also saw you introduced some code for PKRU and the
> > > > > > > > shadow stack
> > > > > > > pointer.
> > > > > > > > We have GDB tests for those registers, too:
> > > > > > > > - gdb.arch/i386-pkru.exp
> > > > > > > > - gdb.arch/amd64-shadow-stack*.exp
> > > > > > >
> > > > > > > For these I just added the equivalent code as is done on
> > > > > > > Linux, without really knowing what they are for.
> > > > > > >
> > > > > > > i386-pkru.exp tells me:
> > > > > > >
> > > > > > > (gdb) print have_pkru()
> > > > > > > $1 = 0
> > > > > > > (gdb) PASS: gdb.arch/i386-pkru.exp: probe PKRU support
> > > > > > > UNSUPPORTED: gdb.arch/i386-pkru.exp: processor does not
> > > > > > > support protection key feature.
> > > > > > >
> > > > > > > Do only certain CPU's have this register?
> > > > > >
> > > > > > Most recent CPUs should have it. To be sure you can check if
> > > > > > the corresponding bit is configured in xcr0.
> > > > >
> > > > > I thought that's what have_pkru() does, but I might be wrong about that.
> > > >
> > > > Yes, this should work for windows, too.
> > > >
> > > > > > I believe for windows this should be the mask returned by
> > > > > get_xstate_features_mask.
> > > > >
> > > > > You probably mean GetEnabledXStateFeatures, but yes, it also
> > > > > tells me my CPU doesn't support this.
> > > > >
> > > > >
> > > > > > If your cpu does have it, I think you must look at the test in
> > > > > > more detail to find out why it's unsupported. It might need
> > > > > > some adaptions for
> > > > > windows.
> > > > > Google tells me only not all recent CPUs have this, is mine one of them?:
> > > > > 11th Gen Intel(R) Core(TM) i7-11850H
> > > >
> > > > I would have expected this but cannot say for sure.  And I don't
> > > > know the state for Memory Protection Keys windows support.
> > >
> > > I have tested this now on another PC, one where have_pkru() returns
> > > 1, so this CPU really should have PKRU.
> > >
> > > But GetEnabledXStateFeatures still does not return the PKRU bit, and
> > > I can find no equivalent XSTATE_PKRU define in winnt.h, this makes
> > > me believe that windows just doesn't support this feature.
> > >
> > > So I'm fine with removing that part.
> > >
> > >
> > > > > > > And amd64-shadow-stack.exp:
> > > > > > >
> > > > > > > (gdb) print $pl3_ssp
> > > > > > > $1 = (void *) 0x0
> > > > > > > (gdb) FAIL: gdb.arch/amd64-shadow-stack.exp: test shadow
> > > > > > > stack support
> > > > > > >
> > > > > > > No idea if that should work, since Windows is supplying data
> > > > > > > for the $pl3_ssp register.
> > > > > > >
> > > > > > >
> > > > > > > Hannes
> > > > > >
> > > > > > Without knowing any of the details in windows I believe adding
> > > > > > full support for CET shadow stack might need some more
> > > > > > changes. At least for
> > > > > linux, this was the case:
> > > > > > https://inbox.sourceware.org/gdb-patches/20250821171029.155560
> > > > > > 3-1-
> > > > > > chri
> > > > > > stina.schimpe@intel.com/
> > > > > >
> > > > > > I believe it would be better to handle this in a separate patch-(series).
> > > > > > This also applies for any other register that you add and
> > > > > > whose dedicated
> > > > > test does not pass.
> > > > > >
> > > > > > Does that make sense to you?
> > > > >
> > > > > I was wondering if it isn't the compiler or linker on windows
> > > > > (or maybe windows itself?) that doesn't support this -fcf-
> protection=return stuff.
> > > >
> > > > I don't know the state for windows but would be curious about it.
> > > > :-) At least for Kernel Mode, I could find some documentation for it.
> > >
> > > I did some more tests here as well.
> > >
> > > 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.
> > >
> > > So I had this wrong, because LocateXStateFeature returns for
> > >XSTATE_CET_U this
> > > struct:
> > >     typedef struct _XSAVE_CET_U_FORMAT {
> > >       DWORD64 Ia32CetUMsr;
> > >       DWORD64 Ia32Pl3SspMsr;
> > >     } XSAVE_CET_U_FORMAT, *PXSAVE_CET_U_FORMAT;
> > >
> > > So $pl3_ssp showed Ia32CetUMsr, when it should have shown
> > > Ia32Pl3SspMsr instead.
> > >
> > > With that fixed, I tried again debugging the /CETCOMPAT executable:
> >
> > Ah ok, good to know.
> >
> > > (gdb) r
> > > Starting program: C:\qiewer\git\amd64-shadow-stack.exe
> > >
> > > Breakpoint 1, 0x00007ff725812e41 in ?? ()
> > > 1: $pl3_ssp = (void *) 0x4feff0
> > > (gdb) x/1i $pc
> > > => 0x7ff725812e41:      jmp    0x7ff725817680
> > > (gdb) x/4a $pl3_ssp
> > > 0x4feff0:       0x7ffd62fee957
> > > <KERNEL32!BaseThreadInitThunk+23>        0x7ffd63647c1c
> > > <ntdll!RtlUserThreadStart+44>
> > > 0x4ff000:       Cannot access memory at address 0x4ff000
> > > (gdb) si
> > > ...
> > > (gdb) si
> > > 0x00007ff725817684 in ?? ()
> > > 1: $pl3_ssp = (void *) 0x4feff0
> > > (gdb) x/1i $pc
> > > => 0x7ff725817684:      call   0x7ff725812f1d
> > > (gdb) si
> > > 0x00007ff725812f1d in ?? ()
> > > 1: $pl3_ssp = (void *) 0x4fefe8
> > > (gdb) x/4a $pl3_ssp
> > > 0x4fefe8:       0x7ff725817689  0x7ffd62fee957
> > > <KERNEL32!BaseThreadInitThunk+23>
> > > 0x4feff8:       0x7ffd63647c1c <ntdll!RtlUserThreadStart+44>
> > > Cannot access memory at address 0x4ff000
> > > (gdb) x/1i $pc
> > > => 0x7ff725812f1d:      jmp    0x7ff725817c30
> > > (gdb) si
> > > ...
> > > (gdb) si
> > > 0x00007ff725817cde in ?? ()
> > > 1: $pl3_ssp = (void *) 0x4fefe8
> > > (gdb) x/1i $pc
> > > => 0x7ff725817cde:      ret
> > > (gdb) si
> > > 0x00007ff725817689 in ?? ()
> > > 1: $pl3_ssp = (void *) 0x4feff0
> > > (gdb) x/1i $pc
> > > => 0x7ff725817689:      add    $0x28,%rsp
> > > (gdb) x/4a $pl3_ssp
> > > 0x4feff0:       0x7ffd62fee957
> > > <KERNEL32!BaseThreadInitThunk+23>        0x7ffd63647c1c
> > > <ntdll!RtlUserThreadStart+44>
> > > 0x4ff000:       Cannot access memory at address 0x4ff000
> > > (gdb)
> > >
> > > call and ret modify the shadow stack which is pointed to by
> > > $pl3_ssp, is that how it's supposed to work?
> >
> > Yeah kind of, you can read it up here:
> > https://inbox.sourceware.org/gdb-patches/20250821171029.1555603-9-chri
> > stina.schimpe@intel.com/
> > https://inbox.sourceware.org/gdb-patches/20250821171029.1555603-10-
> chr
> > istina.schimpe@intel.com/
> >
> > > I'm unsure, because amd64-shadow-stack-cmds.exp makes it look like
> > > $pl3_ssp should change when moving up or down the frames.
> >
> > This is also described in the commit message/gdb.texinfo docs.
> > The corresponding test is amd64-shadow-stack-cmds.exp.
> 
> That's more or less working like I thought.
> But why do we unwind $pl3_ssp when moving up the frames, couldn't it just stay
> the same in all frames?

At least on linux this is required to enable the return command, and to show the right shadow stack pointer at each frame level.
Below is a test log from Linux; I hope it is self-explanatory:

~~~
(gdb) print/x $pl3_ssp^M
$1 = 0x7ffff7bfffe8^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: get value of ssp in main
continue^M
Continuing.^M
^M
Breakpoint 2, call1 () at /tmp/amd64-shadow-stack.c:27^M
27        return call2 (); /* break call1.  */^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: continue to breakpoint: break call1
print/x $pl3_ssp^M
$2 = 0x7ffff7bfffe0^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: get value of ssp in call1
continue^M
Continuing.^M
^M
Breakpoint 3, call2 () at /tmp/amd64-shadow-stack.c:21^M
21        return 42; /* break call2.  */^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: continue to breakpoint: break call2
print/x $pl3_ssp^M
$3 = 0x7ffff7bfffd8^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: get value of ssp in call2
up^M
#1  0x0000555555555142 in call1 () at /tmp/amd64-shadow-stack.c:27^M
27        return call2 (); /* break call1.  */^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: test frame level update: move to frame 1
print /x $pl3_ssp^M
$4 = 0x7ffff7bfffe0^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: test frame level update: check pl3_ssp of frame 1
up^M
#2  0x0000555555555153 in main () at /tmp/amd64-shadow-stack.c:38^M
38        call1 (); /* break main.  */^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: test frame level update: move to frame 2
print /x $pl3_ssp^M
$5 = 0x7ffff7bfffe8^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: test frame level update: check pl3_ssp of frame 2
frame 0^M
#0  call2 () at /tmp/amd64-shadow-stack.c:21^M
21        return 42; /* break call2.  */^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: test frame level update: move to frame 0
print /x $pl3_ssp^M
$6 = 0x7ffff7bfffd8^M
(gdb) PASS: /tmp/amd64-shadow-stack-cmds.exp: test frame level update: check pl3_ssp of frame 0
return (int) 1^M
Make call2 return now? (y or n) y^M
#0  call1 () at /tmp/amd64-shadow-stack.c:28^M
28      }^M
(gdb) PASS: gdb.arch/amd64-shadow-stack-cmds.exp: test return from current frame: Test shadow stack return from current frame
continue^M
Continuing.^M
[Inferior 1 (process 1973699) exited normally]^M
~~~

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.