RE: [PATCH 2/2] gdb, gdbserver: Add Intel APX register support

["Schimpe, Christina" <christina.schimpe@intel.com>]

Hi Keith, 

In this email, I will reply only to the question about i387_fallback_xsave_layout, as it touches on a topic with quite a bit of background. 

> -----Original Message-----
> From: Keith Seitz <keiths@redhat.com>
> Sent: Donnerstag, 18. Juni 2026 19:34
> To: Schimpe, Christina <christina.schimpe@intel.com>; gdb-
> patches@sourceware.org
> Cc: hjl.tools@gmail.com
> Subject: Re: [PATCH 2/2] gdb, gdbserver: Add Intel APX register support
> 
> Hi,
> 
> On 6/2/26 4:11 AM, Christina Schimpe wrote:
> > From: "H.J. Lu" <hjl.tools@gmail.com>
> >
> > Intel(R) Advanced Performance Extensions (APX) doubles the number of
> > general-purpose registers (GPRs) from 16 to 32 (r16-r31).
> >
> > Those new 64-bit Extended GPRs (EGPRs) do not change the size of the
> > XSAVE area, as they take up the space left behind by the deprecated
> > MPX registers.
> >
> > In contrast to the legacy GPRS, EGPRs are not enabled by default in
> > 64-bit mode but are xcr0 enabled based on APX_F Intel APX state.
> > Define X86_XSTATE_APX_F to support this new configuration.
> >
> > Add gdb and gdbserver registers support for those new 64-bit EGPRs.
> > Also add byte, word and dword pseudo register support.
> 
> This patch largely looks good, but I do have a question (and some minor
> formatting nits) below...
> 
> > diff --git a/gdb/i387-tdep.c b/gdb/i387-tdep.c index
> > f33f5ad046e..2b58375eefb 100644
> > --- a/gdb/i387-tdep.c
> > +++ b/gdb/i387-tdep.c
> > @@ -920,6 +948,7 @@ i387_guess_xsave_layout (uint64_t xcr0, size_t
> xsave_size,
> >       {
> >         /* Intel CPUs supporting PKRU.  */
> >         layout.avx_offset = 576;
> > +      layout.apx_offset = 960;
> >         layout.k_offset = 1088;
> >         layout.zmm_h_offset = 1152;
> >         layout.zmm_offset = 1664;
> > @@ -938,6 +967,7 @@ i387_guess_xsave_layout (uint64_t xcr0, size_t
> xsave_size,
> >       {
> >         /* Intel CPUs supporting AVX512.  */
> >         layout.avx_offset = 576;
> > +      layout.apx_offset = 960;
> >         layout.k_offset = 1088;
> >         layout.zmm_h_offset = 1152;
> >         layout.zmm_offset = 1664;
> > @@ -968,6 +998,7 @@ i387_fallback_xsave_layout (uint64_t xcr0)
> >       {
> >         /* Intel CPUs supporting PKRU.  */
> >         layout.avx_offset = 576;
> > +      layout.apx_offset = 960;
> >         layout.k_offset = 1088;
> >         layout.zmm_h_offset = 1152;
> >         layout.zmm_offset = 1664;
> > @@ -978,6 +1009,7 @@ i387_fallback_xsave_layout (uint64_t xcr0)
> >       {
> >         /* Intel CPUs supporting AVX512.  */
> >         layout.avx_offset = 576;
> > +      layout.apx_offset = 960;
> >         layout.k_offset = 1088;
> >         layout.zmm_h_offset = 1152;
> >         layout.zmm_offset = 1664;
> 
> I have a (probably naive) question about 'apx_layout' in the various
> supported configurations. As patched, this member is set when XCR0 has a bit
> set for PKRU or AVX512 support. Does this mean that EGPR reads from core
> files with only "plain" AVX support will be incorrect (at offest 0 instead of
> 960)? AFAICT, the set of features described by XCR0 are independent of each
> other, e.g., having PKRU does not mean that APX is enabled/supported.

Yes, in theory every xsave feature is totally independent from each other.

However, our assumption for known Intel CPUs is that apx is possible
- with amx (this case is only implemented for gdb-oneapi, since amx is not yet merged upstream)
- with pkru (without amx)
- with avx512 (without pkru, amx)

> This may be a paper-only issue, but perhaps a little defensive programming
> might be in order?

This function should be replaced one day with a proper solution. 

See
"The long term solution is to pull the CPUID info from gdbserver in the form of NT_X86_CPUID, but in the short term we could just always use the Intel layout that GDB assumed before the XSAVE series.  That is, we could pick a default layout based on the XCR0 mask that corresponds to one of the known sizes and use that to set both the layout and size.  I'll see if I can't come up with a variant of that today or tomorrow."
https://sourceware.org/bugzilla/show_bug.cgi?id=30912

I believe for now we must live with that heuristic. Adding @Simon Marchi to confirm.

Christina
Intel Deutschland GmbH

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928