[PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with Intel AMX support.

[PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with Intel AMX support.

[Christina Joos]

This patch addresses the issue described in PR gdb/34561.  On systems
with Intel AMX support the xsave size is 11008.  This xsave size is not
handled by gdb/i387-tdep.c:i387_guess_xsave_layout and is causing
problems for corefiles generated by the linux kernel.  The problem is
visible regardless of the AMX enablement state in the dumping process,
so all corefiles on newer systems with AMX are broken.

~~~
$ gdb
GNU gdb (GDB) 19.0.50.20260814-git
Copyright (C) 2026 Free Software Foundation, Inc.
[...]
(gdb) core core_main_SEGV
[New LWP 2162880 (id 1)]
[...]
Core was generated by `./main'.
Program terminated with signal SIGSEGV, Segmentation fault.
4         *pointer = 3;
(gdb) p $ymm0
$1 = void
~~~

We should be able to print the register $ymm0 (or any other register
belonging to a feature higher than SSE).

For a live debug session we can print it:
~~~
Reading symbols from main...
(gdb) start
Temporary breakpoint 1 at 0x1131: file main.c, line 3.
Starting program: /tmp/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main () at main.c:3
3         int *pointer = 0;
(gdb) p $ymm0
$1 = {v16_bfloat16 = {0, 2.342e-38, 0 <repeats 14 times>}, v16_half = {0, 1.5199e-05, 0 <repeats 14 times>}, v8_float = {
    2.34180515e-38, 0, 0, 0, 0, 0, 0, 0}, v4_double = {8.256666972292243e-317, 0, 0, 0}, v32_int8 = {0, 0, -1,
    0 <repeats 29 times>}, v16_int16 = {0, 255, 0 <repeats 14 times>}, v8_int32 = {16711680, 0, 0, 0, 0, 0, 0, 0}, v4_int64 = {
    16711680, 0, 0, 0}, v2_int128 = {16711680, 0}}
[...]
~~~

Note that this is not reproducible for corefiles generated by the gcore
command, since in such corefiles the GDB target description is
available and gdb/i387-tdep.c:i387_fallback_xsave_layout configures
the xsave_layout based on xcr0 derived from the target description.

This patch fixes this issue by handling the new xsave size in
i387_guess_xsave_layout.  It is necessary even though GDB does not
support AMX yet, since we still pass the full xsave_size (11008)
extracted from the corefile to i387_guess_xsave_layout.
The patch does not fix i387_fallback_xsave_layout to configure the new
xsave size.  Configuring sizeof_xsave to 2696 is fine at this point,
since truncating to 2696 drops only the parts GDB doesn't model yet.

As a quick solution for the upcoming release and CPUs supporting
Intel AMX this patch should be sufficient.

Testing:

I noticed that we don't have tests for corefiles for the features AVX,
AVX512 and PKRU in the GDB testsuite.  So this commit adds corefile tests
for AVX, AVX512 and PKRU registers.

As a result of this patch, the warning:

  warning: Unexpected size of section `.reg-xstate/1373786' in core file.

which was causing failure in gdb.base/coredump-filter.exp and
gdb.arch/i386-tls-regs.exp on Intel AMX systems disappears, these tests now
pass.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34561
---
 gdb/i387-tdep.c                        |  9 +++-
 gdb/testsuite/gdb.arch/i386-avx.c      |  9 ++++
 gdb/testsuite/gdb.arch/i386-avx.exp    | 68 +++++++++++++++++++++++---
 gdb/testsuite/gdb.arch/i386-avx512.c   |  9 ++++
 gdb/testsuite/gdb.arch/i386-avx512.exp | 62 +++++++++++++++++++++++
 gdb/testsuite/gdb.arch/i386-pkru.c     |  9 ++++
 gdb/testsuite/gdb.arch/i386-pkru.exp   | 45 +++++++++++++++++
 7 files changed, 201 insertions(+), 10 deletions(-)

diff --git a/gdb/i387-tdep.c b/gdb/i387-tdep.c
index f22a5e02bbb..495c463ed41 100644
--- a/gdb/i387-tdep.c
+++ b/gdb/i387-tdep.c
@@ -918,9 +918,14 @@ bool
 i387_guess_xsave_layout (uint64_t xcr0, size_t xsave_size,
 			 x86_xsave_layout &layout)
 {
-  if (HAS_PKRU (xcr0) && xsave_size == 2696)
+  if (HAS_PKRU (xcr0) && (xsave_size == 2696 || xsave_size == 11008))
     {
-      /* Intel CPUs supporting PKRU.  */
+      /* Intel CPUs supporting PKRU.
+	 In this case two possible XSAVE_SIZE values have to be handled.
+	 As GDB does not yet support Intel AMX and CPUs that support this
+	 feature will have a different XSAVE_SIZE (11008).  If we don't
+	 handle this size then we will not be able to handle any xsave
+	 registers from OS generated core files on AMX systems.  */
       layout.avx_offset = 576;
       layout.k_offset = 1088;
       layout.zmm_h_offset = 1152;
diff --git a/gdb/testsuite/gdb.arch/i386-avx.c b/gdb/testsuite/gdb.arch/i386-avx.c
index b6cd89e5bea..369262857ef 100644
--- a/gdb/testsuite/gdb.arch/i386-avx.c
+++ b/gdb/testsuite/gdb.arch/i386-avx.c
@@ -23,6 +23,8 @@
 /* Align sufficient to be able to use vmovaps.  */
 #define ALIGN 32
 
+volatile int should_dump_core_p = 1;
+
 typedef struct {
   _Alignas (ALIGN) float f[8];
 } v8sf_t;
@@ -87,6 +89,13 @@ main (int argc, char **argv)
 
   asm ("nop"); /* first breakpoint here */
 
+  /* Crash for OS corefile.  */
+  if (should_dump_core_p)
+    {
+      /* Generate SIGSEGV to crash.  */
+      *(volatile int *) 0;
+    };
+
   asm (
        "vmovaps %%ymm0, 0(%0)\n\t"
        "vmovaps %%ymm1, 32(%0)\n\t"
diff --git a/gdb/testsuite/gdb.arch/i386-avx.exp b/gdb/testsuite/gdb.arch/i386-avx.exp
index 1a786ee8a51..ed79a8535c6 100644
--- a/gdb/testsuite/gdb.arch/i386-avx.exp
+++ b/gdb/testsuite/gdb.arch/i386-avx.exp
@@ -42,12 +42,27 @@ if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable \
     return
 }
 
+# Check reading registers after the first breakpoint for ymm int8 and
+# float types.
+proc test_regs_first_bp {} {
+    for { set r 0 } { $r < $::nr_regs } { incr r } {
+	gdb_test "print \$ymm$r.v8_float" \
+	    ".. = \\{$r, $r.125, $r.25, $r.375, $r.5, $r.625, $r.75, $r.875\\}.*" \
+	    "check float contents of %ymm$r"
+	gdb_test "print \$ymm$r.v32_int8" \
+	    ".. = \\{(-?${::decimal}, ){31}-?${::decimal}\\}.*" \
+	    "check int8 contents of %ymm$r"
+    }
+}
+
 clean_restart ${::testfile}
 
 if {![runto_main]} {
     return
 }
 
+gdb_test_no_output "set should_dump_core_p=0"
+
 gdb_test "break [gdb_get_line_number "first breakpoint here"]" \
 	 "Breakpoint .* at .*i386-avx.c.*" \
 	 "set first breakpoint in main"
@@ -59,14 +74,7 @@ if {[is_amd64_regs_target]} {
     set nr_regs 8
 }
 
-for { set r 0 } { $r < $nr_regs } { incr r } {
-    gdb_test "print \$ymm$r.v8_float" \
-	".. = \\{$r, $r.125, $r.25, $r.375, $r.5, $r.625, $r.75, $r.875\\}.*" \
-	"check float contents of %ymm$r"
-    gdb_test "print \$ymm$r.v32_int8" \
-	".. = \\{(-?${::decimal}, ){31}-?${::decimal}\\}.*" \
-	"check int8 contents of %ymm$r"
-}
+test_regs_first_bp
 
 for { set r 0 } { $r < $nr_regs } { incr r } {
     gdb_test "set var \$ymm$r.v8_float\[0\] = $r + 10" "" "set %ymm$r"
@@ -100,9 +108,53 @@ with_test_prefix "force-disable xml descriptions" {
 	    return
 	}
 
+	gdb_test_no_output "set should_dump_core_p=0"
+
 	# With qXfer:features:read disabled, we won't know anything
 	# about YMM registers.
 	gdb_test "print \$ymm0" " = void"
 	gdb_test "print \$xmm0" "v4_float.*"
     }
 }
+
+# Restart gdb, load the corefile generated by gcore or the OS
+# and check reading registers from the corefile.
+proc test_corefile {core_filename} {
+    clean_restart $::testfile
+
+    gdb_test "core $core_filename" "Core was generated by .*" \
+	"load corefile"
+
+    test_regs_first_bp
+}
+
+with_test_prefix "OS generated corefile" {
+    # This test relies on reading address zero triggering a SIGSEGV.
+    # If address zero is readable skip this test.
+    if { [is_address_zero_readable] } {
+	unsupported "address zero is readable"
+    } else {
+	set corefile [core_find $binfile]
+	if { $corefile eq "" } {
+	    unsupported "unable to generate core file"
+	} else {
+	    test_corefile $corefile
+	}
+    }
+}
+
+with_test_prefix "gcore corefile" {
+    clean_restart ${::testfile}
+    if { ![runto_main] } {
+	return
+    }
+
+    set line [gdb_get_line_number "first breakpoint here"]
+    gdb_breakpoint $line
+    gdb_continue_to_breakpoint "first breakpoint here" ".*$srcfile:$line.*"
+
+    set gcorefile $binfile.gcore
+    if { [gdb_gcore_cmd $gcorefile "save a corefile"] } {
+	test_corefile $gcorefile
+    }
+}
diff --git a/gdb/testsuite/gdb.arch/i386-avx512.c b/gdb/testsuite/gdb.arch/i386-avx512.c
index b1e023ce4d4..d3edf780914 100644
--- a/gdb/testsuite/gdb.arch/i386-avx512.c
+++ b/gdb/testsuite/gdb.arch/i386-avx512.c
@@ -19,6 +19,8 @@
 
 #include "x86-cpuid.h"
 
+volatile int should_dump_core_p = 1;
+
 typedef struct
 {
   double f[8];
@@ -233,6 +235,13 @@ main (int argc, char **argv)
       move_zmm_data_to_reg ();
       asm ("nop"); /* third breakpoint here  */
 
+      /* Crash for OS corefile.  */
+      if (should_dump_core_p)
+	{
+	  /* Generate SIGSEGV to crash.  */
+	  *(volatile int *) 0;
+	};
+
       /* Test script incremented values,
 	 move back to array and check values.  */
       move_zmm_data_to_memory ();
diff --git a/gdb/testsuite/gdb.arch/i386-avx512.exp b/gdb/testsuite/gdb.arch/i386-avx512.exp
index c79563366dc..b6834152e8a 100644
--- a/gdb/testsuite/gdb.arch/i386-avx512.exp
+++ b/gdb/testsuite/gdb.arch/i386-avx512.exp
@@ -35,6 +35,8 @@ if {![runto_main]} {
     return
 }
 
+gdb_test_no_output "set should_dump_core_p=0"
+
 set supports_avx512 0
 
 set test "probe AVX512 support"
@@ -181,3 +183,63 @@ gdb_test "print \$zmm0.v16_int32" "= {-1, -1, -1, -1, 0 <repeats 12 times>}"
 if { $nr_regs >= 16 } {
     gdb_test "print \$zmm16.v16_int32" "= {-1 <repeats 16 times>}"
 }
+
+# Test reading k and zmm registers and for double and int16 types.
+proc test_regs_corefile {} {
+    for { set r 1 } { $r < 8 } { incr r } {
+	gdb_test "print/x \$k$r" \
+	    ".. = 0x[format %x $r]2[format %x $r]1" \
+	    "check contents of %k$r"
+    }
+
+    for { set r 0 } { $r < $::nr_regs } { incr r } {
+	gdb_test "print \$zmm$r.v8_double" \
+	    ".. = \\{$r, $r.125, $r.25, $r.375, $r.5, $r.625, $r.75, $r.875\\}.*" \
+	    "check double contents of %zmm$r"
+	gdb_test "print \$zmm$r.v32_int16" \
+	    ".. = \\{(-?${::decimal}, ){31}-?${::decimal}\\}.*" \
+	    "check int16 contents of %zmm$r"
+    }
+}
+
+# Restart gdb, load the corefile generated by gcore or the OS
+# and check reading registers from the corefile.
+proc test_corefile {core_filename} {
+    clean_restart $::testfile
+
+    gdb_test "core $core_filename" "Core was generated by .*" \
+	"load corefile"
+
+    test_regs_corefile
+}
+
+with_test_prefix "OS generated corefile" {
+    # This test relies on reading address zero triggering a SIGSEGV.
+    # If address zero is readable skip this test.
+    if { [is_address_zero_readable] } {
+	unsupported "address zero is readable"
+    } else {
+	set corefile [core_find $binfile]
+	if { $corefile eq "" } {
+	    unsupported "unable to generate core file"
+	} else {
+	    test_corefile $corefile
+	}
+    }
+}
+
+with_test_prefix "gcore corefile" {
+    clean_restart ${::testfile}
+    if { ![runto_main] } {
+	return
+    }
+
+    set line [gdb_get_line_number "third breakpoint here"]
+    gdb_breakpoint $line
+    gdb_continue_to_breakpoint "third breakpoint here" ".*$srcfile:$line.*"
+
+    set gcorefile $binfile.gcore
+    if { [gdb_gcore_cmd $gcorefile "save a corefile"] } {
+	test_corefile $gcorefile
+    }
+}
diff --git a/gdb/testsuite/gdb.arch/i386-pkru.c b/gdb/testsuite/gdb.arch/i386-pkru.c
index 9561d1e923a..159acdea219 100644
--- a/gdb/testsuite/gdb.arch/i386-pkru.c
+++ b/gdb/testsuite/gdb.arch/i386-pkru.c
@@ -24,6 +24,8 @@
 #define NOINLINE __attribute__ ((noinline))
 #endif
 
+volatile int should_dump_core_p = 1;
+
 unsigned int have_pkru (void) NOINLINE;
 
 static inline unsigned long
@@ -83,6 +85,13 @@ main (int argc, char **argv)
       wrpkru (wr_value);
       asm ("nop\n\t");	/* break here 1.  */
 
+      /* Crash for OS corefile.  */
+      if (should_dump_core_p)
+	{
+	  /* Generate SIGSEGV to crash.  */
+	  *(volatile int *) 0;
+	}
+
       rd_value = rdpkru ();
       asm ("nop\n\t");	/* break here 2.  */
     }
diff --git a/gdb/testsuite/gdb.arch/i386-pkru.exp b/gdb/testsuite/gdb.arch/i386-pkru.exp
index b9b0b99b0de..ae90a2bea1a 100644
--- a/gdb/testsuite/gdb.arch/i386-pkru.exp
+++ b/gdb/testsuite/gdb.arch/i386-pkru.exp
@@ -38,6 +38,8 @@ if {![runto_main]} {
     return
 }
 
+gdb_test_no_output "set should_dump_core_p=0"
+
 set supports_pkru 0
 set test "probe PKRU support"
 gdb_test_multiple "print have_pkru()" $test {
@@ -108,3 +110,46 @@ gdb_test_multiple "print /x rd_value" "variable after reading pkru" {
 	}
     }
 }
+
+# Restart gdb, load the corefile generated by gcore or the OS
+# and check reading the pkru register from the corefile.
+proc test_corefile {core_filename} {
+    clean_restart $::testfile
+
+    gdb_test "core $core_filename" "Core was generated by .*" \
+	"load corefile"
+
+    gdb_test "info register pkru" ".*pkru.*$::val1.*" \
+	"read pkru register"
+}
+
+with_test_prefix "OS generated corefile" {
+    # This test relies on reading address zero triggering a SIGSEGV.
+    # If address zero is readable skip this test.
+    if { [is_address_zero_readable] } {
+	unsupported "address zero is readable"
+    } else {
+	set corefile [core_find $binfile]
+	if { $corefile eq "" } {
+	    unsupported "unable to generate core file"
+	} else {
+	    test_corefile $corefile
+	}
+    }
+}
+
+with_test_prefix "gcore corefile" {
+    clean_restart ${::testfile}
+    if { ![runto_main] } {
+	return
+    }
+
+    set line [gdb_get_line_number "break here 1"]
+    gdb_breakpoint $line
+    gdb_continue_to_breakpoint "break here 1" ".*$srcfile:$line.*"
+
+    set gcorefile $binfile.gcore
+    if { [gdb_gcore_cmd $gcorefile "save a corefile"] } {
+	test_corefile $gcorefile
+    }
+}
-- 
2.53.0

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

Re: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with Intel AMX support.

[Andrew Burgess]

Christina Joos <christina.joos@intel.com> writes:

> This patch addresses the issue described in PR gdb/34561.  On systems
> with Intel AMX support the xsave size is 11008.  This xsave size is not
> handled by gdb/i387-tdep.c:i387_guess_xsave_layout and is causing
> problems for corefiles generated by the linux kernel.  The problem is
> visible regardless of the AMX enablement state in the dumping process,
> so all corefiles on newer systems with AMX are broken.
>
> ~~~
> $ gdb
> GNU gdb (GDB) 19.0.50.20260814-git
> Copyright (C) 2026 Free Software Foundation, Inc.
> [...]
> (gdb) core core_main_SEGV
> [New LWP 2162880 (id 1)]
> [...]
> Core was generated by `./main'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> 4         *pointer = 3;
> (gdb) p $ymm0
> $1 = void
> ~~~
>
> We should be able to print the register $ymm0 (or any other register
> belonging to a feature higher than SSE).
>
> For a live debug session we can print it:
> ~~~
> Reading symbols from main...
> (gdb) start
> Temporary breakpoint 1 at 0x1131: file main.c, line 3.
> Starting program: /tmp/main
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Temporary breakpoint 1, main () at main.c:3
> 3         int *pointer = 0;
> (gdb) p $ymm0
> $1 = {v16_bfloat16 = {0, 2.342e-38, 0 <repeats 14 times>}, v16_half = {0, 1.5199e-05, 0 <repeats 14 times>}, v8_float = {
>     2.34180515e-38, 0, 0, 0, 0, 0, 0, 0}, v4_double = {8.256666972292243e-317, 0, 0, 0}, v32_int8 = {0, 0, -1,
>     0 <repeats 29 times>}, v16_int16 = {0, 255, 0 <repeats 14 times>}, v8_int32 = {16711680, 0, 0, 0, 0, 0, 0, 0}, v4_int64 = {
>     16711680, 0, 0, 0}, v2_int128 = {16711680, 0}}
> [...]
> ~~~
>
> Note that this is not reproducible for corefiles generated by the gcore
> command, since in such corefiles the GDB target description is
> available and gdb/i387-tdep.c:i387_fallback_xsave_layout configures
> the xsave_layout based on xcr0 derived from the target description.
>
> This patch fixes this issue by handling the new xsave size in
> i387_guess_xsave_layout.  It is necessary even though GDB does not
> support AMX yet, since we still pass the full xsave_size (11008)
> extracted from the corefile to i387_guess_xsave_layout.
> The patch does not fix i387_fallback_xsave_layout to configure the new
> xsave size.  Configuring sizeof_xsave to 2696 is fine at this point,
> since truncating to 2696 drops only the parts GDB doesn't model yet.
>
> As a quick solution for the upcoming release and CPUs supporting
> Intel AMX this patch should be sufficient.
>
> Testing:
>
> I noticed that we don't have tests for corefiles for the features AVX,
> AVX512 and PKRU in the GDB testsuite.  So this commit adds corefile tests
> for AVX, AVX512 and PKRU registers.
>
> As a result of this patch, the warning:
>
>   warning: Unexpected size of section `.reg-xstate/1373786' in core file.
>
> which was causing failure in gdb.base/coredump-filter.exp and
> gdb.arch/i386-tls-regs.exp on Intel AMX systems disappears, these tests now
> pass.
>
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34561

Thanks for your work on this patch.

I added a NEWS file entry for this as it felt like something that was
NEWS worthy, especially on the gdb-18-branch.

I also changed "corefile" to "core file" in the commit message and
comments.

Then I pushed this to master and gdb-18-branch.

Thanks,
Andrew

Re: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with Intel AMX support.

[Andrew Burgess]

Christina Joos <christina.joos@intel.com> writes:

> This patch addresses the issue described in PR gdb/34561.  On systems
> with Intel AMX support the xsave size is 11008.  This xsave size is not
> handled by gdb/i387-tdep.c:i387_guess_xsave_layout and is causing
> problems for corefiles generated by the linux kernel.  The problem is
> visible regardless of the AMX enablement state in the dumping process,
> so all corefiles on newer systems with AMX are broken.

FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=34646

Could you take a look if you have a chance please.

Thanks,
Andrew

RE: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with Intel AMX support.

[Joos, Christina]

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Samstag, 19. September 2026 13:55
> To: Joos, Christina <christina.joos@intel.com>; gdb-patches@sourceware.org
> Cc: Rohr, Stephan <stephan.rohr@intel.com>
> Subject: Re: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with
> Intel AMX support.
> 
> Christina Joos <christina.joos@intel.com> writes:
> 
> > This patch addresses the issue described in PR gdb/34561.  On systems
> > with Intel AMX support the xsave size is 11008.  This xsave size is
> > not handled by gdb/i387-tdep.c:i387_guess_xsave_layout and is causing
> > problems for corefiles generated by the linux kernel.  The problem is
> > visible regardless of the AMX enablement state in the dumping process,
> > so all corefiles on newer systems with AMX are broken.

Hi Andrew,

Thanks a lot for pushing this patch.

> FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=34646
> Could you take a look if you have a chance please.

As described in the discussion for v1 of this patch [1], the issue described in the bug
34646, just became visible due to the improved test coverage for core files, which
are also part of this patch.
They are unrelated to the GDB code changes of this patch, so the issue existed before,
too. I added a comment in the bug, so this is hopefully clearer now.

[1] https://sourceware.org/pipermail/gdb-patches/2026-September/230279.html

Kind Regards,
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.

RE: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with Intel AMX support.

[Andrew Burgess]

"Joos, Christina" <christina.joos@intel.com> writes:

>> -----Original Message-----
>> From: Andrew Burgess <aburgess@redhat.com>
>> Sent: Samstag, 19. September 2026 13:55
>> To: Joos, Christina <christina.joos@intel.com>; gdb-patches@sourceware.org
>> Cc: Rohr, Stephan <stephan.rohr@intel.com>
>> Subject: Re: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with
>> Intel AMX support.
>> 
>> Christina Joos <christina.joos@intel.com> writes:
>> 
>> > This patch addresses the issue described in PR gdb/34561.  On systems
>> > with Intel AMX support the xsave size is 11008.  This xsave size is
>> > not handled by gdb/i387-tdep.c:i387_guess_xsave_layout and is causing
>> > problems for corefiles generated by the linux kernel.  The problem is
>> > visible regardless of the AMX enablement state in the dumping process,
>> > so all corefiles on newer systems with AMX are broken.
>
> Hi Andrew,
>
> Thanks a lot for pushing this patch.
>
>> FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=34646
>> Could you take a look if you have a chance please.
>
> As described in the discussion for v1 of this patch [1], the issue described in the bug
> 34646, just became visible due to the improved test coverage for core files, which
> are also part of this patch.
> They are unrelated to the GDB code changes of this patch, so the issue existed before,
> too. I added a comment in the bug, so this is hopefully clearer now.
>
> [1] https://sourceware.org/pipermail/gdb-patches/2026-September/230279.html

Thanks for the explanation.  This makes sense.

Would you be OK if I pushed the patch below to master and gdb-18-branch?

This converts the FAIL to XFAIL and points back at PR gdb/34646.  I did
consider creating a brand new bug, but that seemed a little pointless.

Thanks,
Andrew

~~~

commit 95bb312d0f65229d914adffe143c6e561cb285bf
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Mon Sep 21 10:12:44 2026 +0100

    gdb/testsuite: add xfail to gdb.arch/i386-pkru.exp test script
    
    Add an xfail to the new gdb.arch/i386-pkru.exp test script, which is
    currently failing due to a preexisting issue.  The test script was
    added to master in commit:
    
      commit eec39a2f9250c622d86219cc182c4feaa6b07c50
      Date:   Fri Sep 11 18:30:01 2026 +0200
    
        gdb: Enable OS generated core files on systems with Intel AMX support
    
    And back-ported to gdb-18-branch in commit:
    
      commit 1d77334943a940a0384f6177cc8ceb9dd3852c17
      Date:   Fri Sep 11 18:30:01 2026 +0200
    
        gdb: Enable OS generated core files on systems with Intel AMX support
    
    The test triggers the OS to generate a core file.  GDB then loads the
    core file and inspects the PKRU register.  Currently, this register
    does not contain the expected value.  This is an existing issue that
    existed before the above commit(s).
    
    As it is not good to introduce new FAILs, I'm changing the test to
    report XFAIL if we get anything other than the expected PKRU value.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34646

diff --git a/gdb/testsuite/gdb.arch/i386-pkru.exp b/gdb/testsuite/gdb.arch/i386-pkru.exp
index 07a589cba82..926cc7dbfff 100644
--- a/gdb/testsuite/gdb.arch/i386-pkru.exp
+++ b/gdb/testsuite/gdb.arch/i386-pkru.exp
@@ -113,14 +113,24 @@ gdb_test_multiple "print /x rd_value" "variable after reading pkru" {
 
 # Restart gdb, load the core file generated by gcore or the OS
 # and check reading the pkru register from the core file.
-proc test_corefile {core_filename} {
+proc test_corefile { core_filename { allow_xfail false } } {
     clean_restart $::testfile
 
     gdb_test "core $core_filename" "Core was generated by .*" \
 	"load core file"
 
-    gdb_test "info register pkru" ".*pkru.*$::val1.*" \
-	"read pkru register"
+    gdb_test_multiple "info register pkru" "read pkru register" {
+	-re -wrap ".*pkru.*$::val1.*" {
+	    pass $gdb_test_name
+	}
+	-re -wrap ".*pkru.*" {
+	    if { $allow_xfail } {
+		xfail "$gdb_test_name (PR gdb/34646)"
+	    } else {
+		fail $gdb_test_name
+	    }
+	}
+    }
 }
 
 with_test_prefix "OS generated core file" {
@@ -133,7 +143,7 @@ with_test_prefix "OS generated core file" {
 	if { $corefile eq "" } {
 	    unsupported "unable to generate core file"
 	} else {
-	    test_corefile $corefile
+	    test_corefile $corefile true
 	}
     }
 }

RE: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with Intel AMX support.

[Joos, Christina]

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Montag, 21. September 2026 12:05
> To: Joos, Christina <christina.joos@intel.com>; gdb-patches@sourceware.org
> Cc: Rohr, Stephan <stephan.rohr@intel.com>
> Subject: RE: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems
> with Intel AMX support.
> 
> "Joos, Christina" <christina.joos@intel.com> writes:
> 
> >> -----Original Message-----
> >> From: Andrew Burgess <aburgess@redhat.com>
> >> Sent: Samstag, 19. September 2026 13:55
> >> To: Joos, Christina <christina.joos@intel.com>;
> >> gdb-patches@sourceware.org
> >> Cc: Rohr, Stephan <stephan.rohr@intel.com>
> >> Subject: Re: [PATCH v2 1/1] gdb: Enable OS generated corefiles on
> >> systems with Intel AMX support.
> >>
> >> Christina Joos <christina.joos@intel.com> writes:
> >>
> >> > This patch addresses the issue described in PR gdb/34561.  On
> >> > systems with Intel AMX support the xsave size is 11008.  This xsave
> >> > size is not handled by gdb/i387-tdep.c:i387_guess_xsave_layout and
> >> > is causing problems for corefiles generated by the linux kernel.
> >> > The problem is visible regardless of the AMX enablement state in
> >> > the dumping process, so all corefiles on newer systems with AMX are
> broken.
> >
> > Hi Andrew,
> >
> > Thanks a lot for pushing this patch.
> >
> >> FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=34646
> >> Could you take a look if you have a chance please.
> >
> > As described in the discussion for v1 of this patch [1], the issue
> > described in the bug 34646, just became visible due to the improved
> > test coverage for core files, which are also part of this patch.
> > They are unrelated to the GDB code changes of this patch, so the issue
> > existed before, too. I added a comment in the bug, so this is hopefully clearer
> now.
> >
> > [1]
> > https://sourceware.org/pipermail/gdb-patches/2026-
> September/230279.htm
> > l
> 
> Thanks for the explanation.  This makes sense.
> 
> Would you be OK if I pushed the patch below to master and gdb-18-branch?
> 
> This converts the FAIL to XFAIL and points back at PR gdb/34646.  I did
> consider creating a brand new bug, but that seemed a little pointless.
> 
> Thanks,
> Andrew
> 
> ~~~
> 
> commit 95bb312d0f65229d914adffe143c6e561cb285bf
> Author: Andrew Burgess <aburgess@redhat.com>
> Date:   Mon Sep 21 10:12:44 2026 +0100
> 
>     gdb/testsuite: add xfail to gdb.arch/i386-pkru.exp test script
> 
>     Add an xfail to the new gdb.arch/i386-pkru.exp test script, which is
>     currently failing due to a preexisting issue.  The test script was
>     added to master in commit:
> 
>       commit eec39a2f9250c622d86219cc182c4feaa6b07c50
>       Date:   Fri Sep 11 18:30:01 2026 +0200
> 
>         gdb: Enable OS generated core files on systems with Intel AMX support
> 
>     And back-ported to gdb-18-branch in commit:
> 
>       commit 1d77334943a940a0384f6177cc8ceb9dd3852c17
>       Date:   Fri Sep 11 18:30:01 2026 +0200
> 
>         gdb: Enable OS generated core files on systems with Intel AMX support
> 
>     The test triggers the OS to generate a core file.  GDB then loads the
>     core file and inspects the PKRU register.  Currently, this register
>     does not contain the expected value.  This is an existing issue that
>     existed before the above commit(s).

The issue is not reproducible on every machine. 
It might make sense to add a comment about that, but since the issue is not yet
fully understood, it would have to be very vague, for instance:

"Currently, this register does not contain the expected value on some machines."

For me, both options would be fine (your version or my version).

>     As it is not good to introduce new FAILs, I'm changing the test to
>     report XFAIL if we get anything other than the expected PKRU value.
> 
>     Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34646

Ah, ok - I wasn't sure what the process is in such cases.

If someone looks at this GDB ticket, they can read the comments in the bug
and will be aware that this issue is not yet understood and may depend on
the environment rather than GDB. So, this is fine from my side.

> diff --git a/gdb/testsuite/gdb.arch/i386-pkru.exp
> b/gdb/testsuite/gdb.arch/i386-pkru.exp
> index 07a589cba82..926cc7dbfff 100644
> --- a/gdb/testsuite/gdb.arch/i386-pkru.exp
> +++ b/gdb/testsuite/gdb.arch/i386-pkru.exp
> @@ -113,14 +113,24 @@ gdb_test_multiple "print /x rd_value" "variable after
> reading pkru" {
> 
>  # Restart gdb, load the core file generated by gcore or the OS  # and check
> reading the pkru register from the core file.
> -proc test_corefile {core_filename} {
> +proc test_corefile { core_filename { allow_xfail false } } {
>      clean_restart $::testfile
> 
>      gdb_test "core $core_filename" "Core was generated by .*" \
>  	"load core file"
> 
> -    gdb_test "info register pkru" ".*pkru.*$::val1.*" \
> -	"read pkru register"
> +    gdb_test_multiple "info register pkru" "read pkru register" {
> +	-re -wrap ".*pkru.*$::val1.*" {
> +	    pass $gdb_test_name
> +	}
> +	-re -wrap ".*pkru.*" {
> +	    if { $allow_xfail } {
> +		xfail "$gdb_test_name (PR gdb/34646)"
> +	    } else {
> +		fail $gdb_test_name
> +	    }
> +	}
> +    }
>  }
> 
>  with_test_prefix "OS generated core file" { @@ -133,7 +143,7 @@
> with_test_prefix "OS generated core file" {
>  	if { $corefile eq "" } {
>  	    unsupported "unable to generate core file"
>  	} else {
> -	    test_corefile $corefile
> +	    test_corefile $corefile true
>  	}
>      }
>  }

As described above, I only have one suggestion for the commit message.
I will leave this up to you to change.

Since both commit message versions would work for me:

Approved-By: Christina Joos <christina.joos@intel.com>

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.

RE: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems with Intel AMX support.

[Andrew Burgess]

"Joos, Christina" <christina.joos@intel.com> writes:

>> -----Original Message-----
>> From: Andrew Burgess <aburgess@redhat.com>
>> Sent: Montag, 21. September 2026 12:05
>> To: Joos, Christina <christina.joos@intel.com>; gdb-patches@sourceware.org
>> Cc: Rohr, Stephan <stephan.rohr@intel.com>
>> Subject: RE: [PATCH v2 1/1] gdb: Enable OS generated corefiles on systems
>> with Intel AMX support.
>> 
>> "Joos, Christina" <christina.joos@intel.com> writes:
>> 
>> >> -----Original Message-----
>> >> From: Andrew Burgess <aburgess@redhat.com>
>> >> Sent: Samstag, 19. September 2026 13:55
>> >> To: Joos, Christina <christina.joos@intel.com>;
>> >> gdb-patches@sourceware.org
>> >> Cc: Rohr, Stephan <stephan.rohr@intel.com>
>> >> Subject: Re: [PATCH v2 1/1] gdb: Enable OS generated corefiles on
>> >> systems with Intel AMX support.
>> >>
>> >> Christina Joos <christina.joos@intel.com> writes:
>> >>
>> >> > This patch addresses the issue described in PR gdb/34561.  On
>> >> > systems with Intel AMX support the xsave size is 11008.  This xsave
>> >> > size is not handled by gdb/i387-tdep.c:i387_guess_xsave_layout and
>> >> > is causing problems for corefiles generated by the linux kernel.
>> >> > The problem is visible regardless of the AMX enablement state in
>> >> > the dumping process, so all corefiles on newer systems with AMX are
>> broken.
>> >
>> > Hi Andrew,
>> >
>> > Thanks a lot for pushing this patch.
>> >
>> >> FYI: https://sourceware.org/bugzilla/show_bug.cgi?id=34646
>> >> Could you take a look if you have a chance please.
>> >
>> > As described in the discussion for v1 of this patch [1], the issue
>> > described in the bug 34646, just became visible due to the improved
>> > test coverage for core files, which are also part of this patch.
>> > They are unrelated to the GDB code changes of this patch, so the issue
>> > existed before, too. I added a comment in the bug, so this is hopefully clearer
>> now.
>> >
>> > [1]
>> > https://sourceware.org/pipermail/gdb-patches/2026-
>> September/230279.htm
>> > l
>> 
>> Thanks for the explanation.  This makes sense.
>> 
>> Would you be OK if I pushed the patch below to master and gdb-18-branch?
>> 
>> This converts the FAIL to XFAIL and points back at PR gdb/34646.  I did
>> consider creating a brand new bug, but that seemed a little pointless.
>> 
>> Thanks,
>> Andrew
>> 
>> ~~~
>> 
>> commit 95bb312d0f65229d914adffe143c6e561cb285bf
>> Author: Andrew Burgess <aburgess@redhat.com>
>> Date:   Mon Sep 21 10:12:44 2026 +0100
>> 
>>     gdb/testsuite: add xfail to gdb.arch/i386-pkru.exp test script
>> 
>>     Add an xfail to the new gdb.arch/i386-pkru.exp test script, which is
>>     currently failing due to a preexisting issue.  The test script was
>>     added to master in commit:
>> 
>>       commit eec39a2f9250c622d86219cc182c4feaa6b07c50
>>       Date:   Fri Sep 11 18:30:01 2026 +0200
>> 
>>         gdb: Enable OS generated core files on systems with Intel AMX support
>> 
>>     And back-ported to gdb-18-branch in commit:
>> 
>>       commit 1d77334943a940a0384f6177cc8ceb9dd3852c17
>>       Date:   Fri Sep 11 18:30:01 2026 +0200
>> 
>>         gdb: Enable OS generated core files on systems with Intel AMX support
>> 
>>     The test triggers the OS to generate a core file.  GDB then loads the
>>     core file and inspects the PKRU register.  Currently, this register
>>     does not contain the expected value.  This is an existing issue that
>>     existed before the above commit(s).
>
> The issue is not reproducible on every machine. 
> It might make sense to add a comment about that, but since the issue is not yet
> fully understood, it would have to be very vague, for instance:
>
> "Currently, this register does not contain the expected value on some machines."
>
> For me, both options would be fine (your version or my version).
>
>>     As it is not good to introduce new FAILs, I'm changing the test to
>>     report XFAIL if we get anything other than the expected PKRU value.
>> 
>>     Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34646
>
> Ah, ok - I wasn't sure what the process is in such cases.
>
> If someone looks at this GDB ticket, they can read the comments in the bug
> and will be aware that this issue is not yet understood and may depend on
> the environment rather than GDB. So, this is fine from my side.
>
>> diff --git a/gdb/testsuite/gdb.arch/i386-pkru.exp
>> b/gdb/testsuite/gdb.arch/i386-pkru.exp
>> index 07a589cba82..926cc7dbfff 100644
>> --- a/gdb/testsuite/gdb.arch/i386-pkru.exp
>> +++ b/gdb/testsuite/gdb.arch/i386-pkru.exp
>> @@ -113,14 +113,24 @@ gdb_test_multiple "print /x rd_value" "variable after
>> reading pkru" {
>> 
>>  # Restart gdb, load the core file generated by gcore or the OS  # and check
>> reading the pkru register from the core file.
>> -proc test_corefile {core_filename} {
>> +proc test_corefile { core_filename { allow_xfail false } } {
>>      clean_restart $::testfile
>> 
>>      gdb_test "core $core_filename" "Core was generated by .*" \
>>  	"load core file"
>> 
>> -    gdb_test "info register pkru" ".*pkru.*$::val1.*" \
>> -	"read pkru register"
>> +    gdb_test_multiple "info register pkru" "read pkru register" {
>> +	-re -wrap ".*pkru.*$::val1.*" {
>> +	    pass $gdb_test_name
>> +	}
>> +	-re -wrap ".*pkru.*" {
>> +	    if { $allow_xfail } {
>> +		xfail "$gdb_test_name (PR gdb/34646)"
>> +	    } else {
>> +		fail $gdb_test_name
>> +	    }
>> +	}
>> +    }
>>  }
>> 
>>  with_test_prefix "OS generated core file" { @@ -133,7 +143,7 @@
>> with_test_prefix "OS generated core file" {
>>  	if { $corefile eq "" } {
>>  	    unsupported "unable to generate core file"
>>  	} else {
>> -	    test_corefile $corefile
>> +	    test_corefile $corefile true
>>  	}
>>      }
>>  }
>
> As described above, I only have one suggestion for the commit message.
> I will leave this up to you to change.
>
> Since both commit message versions would work for me:
>
> Approved-By: Christina Joos <christina.joos@intel.com>
>

I tweaked the commit message as you suggested and pushed this to master
and gdb-18-branch.

Thanks,
Andrew