[Bug gdb/34561] Problem reading OS generated corefiles on systems with Intel AMX support

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

--- Comment #2 from Joos, Christina <christina.joos at intel dot com> ---
A pretty straight-foward fix for this is the following:

~~~
 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.
+        Note that in this case 2 possible xsave_sizes have to be handled,
+        since GDB does not support AMX yet, but CPUs that support AMX
+        still have a different xsave size (xsave_size == 11008).
+        Otherwise, we are not able to read xsave registers in OS generated
+        corefiles.  */
       layout.avx_offset = 576;
       layout.k_offset = 1088;
       layout.zmm_h_offset = 1152;
~~~

For now I cannot fix this in a forward compatible way, as we use the xsave size
to distinguish between AMD and Intel CPUs. So IMO, this is the most straight
forward change, especially for the upcoming GDB 18 release.

I don't think it is necessary to fixup i387_fallback_xsave_layout. This
fallback is used for remote targets when writing a corefile with gcore.
Using sizeof_xsave == 2696 is fine, since truncating to 2696 drops
only the parts GDB doesn't model.  Once GDB properly supports Intel AMX,
this for sure has to be changed.

Patches for the the long term solution have been posted last year:
https://inbox.sourceware.org/gdb-patches/[email protected]/

TESTING:
My current patch (shared above) fixes the test gdb.base/coredump-filter.exp
on systems with Intel AMX support:
~~~
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M
Core was generated by `/tmp/gdb.base/coredump-filter/coredump-filter'.^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
warning: Unexpected size 11008 of section `.reg-xstate/1373786' in core file.
Expected section_min_size = 2696^M
#0  main (argc=1, argv=0x7fffffffdd98) at /tmp/gdb.base/coredump-filter.c:60^M
60        return 0; /* break-here */^M
(gdb) PASS: gdb.base/coredump-filter.exp: disassembling function main for
DoNotDump: no binary: load core
with confirm off -- file^M
No executable file now.^M
No symbol file now.^M
warning: Unexpected size  of section `.reg-xstate/1373786' in core file.^M
(gdb) FAIL: gdb.base/coredump-filter.exp: disassembling function main for
DoNotDump: no binary: ensure no executable is loaded
~~~

With my patch the warning 
"warning: Unexpected size  of section `.reg-xstate/1373786' in core file.^M"
disappears.

I also think we should extend the GDB testsuite for OS generated corefiles.
I noticed that we don't have any specific tests for corefiles for the registers
belonging to avx, avx512, pkru.

The general test gdb.base/gcore.exp is covering those registers at least
partially for the gcore command, but OS generated corefiles are missing.

So my current thinking is either to
a) add new dedicated  gcore and OS generated corefiles tests in gdb.arch for
avx, avx512, pkru
b) add a new general tests for OS generated corefiles in gdb.base similar to
gdb.base/gcore.exp.

My current preference is a). We already have a similar test for corefiles
including
the shadow stack pointer and I will probably add a new one for APX:
https://sourceware.org/pipermail/gdb-patches/2026-July/228991.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.