RE: [PATCH 1/1] gdb, gdbserver: Add Intel APX register support
"Joos, Christina" <[email protected]>
| Newsgroups | gmane.comp.gdb.patches |
|---|---|
| Message-ID | <SN7PR11MB76383F1926F3C42A77F8B4BC89AF2@SN7PR11MB7638.namprd11.prod.outlook.com> |
> -----Original Message----- > From: Keith Seitz <[email protected]> > Sent: Donnerstag, 13. August 2026 20:14 > To: Joos, Christina <[email protected]>; [email protected] > Subject: Re: [PATCH 1/1] gdb, gdbserver: Add Intel APX register support > > Hi, > > On 7/25/26 3:53 AM, Christina Joos wrote: > > From: "H.J. Lu" <[email protected]> > > > > Intel Advanced Performance Extensions (APX) doubles the number of > > general-purpose registers (GPRs) from 16 to 32 (r16-r31). > > Thank you for pursuing this. I'm not going to claim that I completely understand > the nuiance of modern x86_64 features, but generally, the code seems okay to > me. > > > 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. > > I appreciate the simplified approach in this revision, removing the previously > proposed maint commands. Generating core files is much better/safe approach. > > One trivial nit (no need to repost): > I previously asked whether apx_offset should be set independently of > PKRU/AVX512 in i387_guess_xsave_layout()[1]. You explained that APX is only > expected with PKRU or AVX512 on known Intel CPUs addresses[2]. > > A brief comment documenting that assumption would be helpful for future > readers. 'Cause, as expected, I forgot all about that discussion already! 😝 I just found a bug in this area: https://sourceware.org/bugzilla/show_bug.cgi?id=34561 Assuming a fix like the one indicated in comment of the bug will be merged before this patch I think we can add something like this on top: ~~~ diff --git a/gdb/i387-tdep.c b/gdb/i387-tdep.c index 51459c31dcc..51180714e08 100644 --- a/gdb/i387-tdep.c +++ b/gdb/i387-tdep.c @@ -955,6 +955,8 @@ i387_guess_xsave_layout (uint64_t xcr0, size_t xsave_size, Otherwise, we are not able to read xsave registers in OS generated corefiles. */ layout.avx_offset = 576; + /* Intel APX can be available on CPUs with PKRU including AMX or not + including AMX support. */ layout.apx_offset = 960; layout.k_offset = 1088; layout.zmm_h_offset = 1152; @@ -974,6 +976,7 @@ i387_guess_xsave_layout (uint64_t xcr0, size_t xsave_size, { /* Intel CPUs supporting AVX512. */ layout.avx_offset = 576; + /* Intel APX can be available on CPUs supporting AVX512. */ layout.apx_offset = 960; layout.k_offset = 1088; layout.zmm_h_offset = 1152; ~~~ Or do you have a different comment in mind? > Reviewed-By: Keith Seitz <[email protected]> > > Keith > > [1] https://sourceware.org/pipermail/gdb-patches/2026-June/228135.html > [2] https://sourceware.org/pipermail/gdb-patches/2026-July/228491.html My original plan was to post this patch once again including the fixes for Eli's feedback + ones pointed out by me here https://sourceware.org/pipermail/gdb-patches/2026-August/229759.html and then wait 1-2 weeks and merge it if there is no more feedback. Since it's only in the x86 area I think it should be fine for me to self-approve here. However, in the meantime this bug mentioned above popped up. I think it makes sense to wait until this is resolved. 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.