Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: "Joos, Christina" <christina.joos@intel.com>,
	"gdb-patches@sourceware.org" <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.
Date: Mon, 21 Sep 2026 11:04:48 +0100	[thread overview]
Message-ID: <87v77yapj3.fsf@redhat.com> (raw)
In-Reply-To: <SN7PR11MB763889147C0993348AFA5D0689842@SN7PR11MB7638.namprd11.prod.outlook.com>

"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
 	}
     }
 }


  reply	other threads:[~2026-09-21 10:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-11 16:30 Christina Joos
2026-09-15 15:06 ` Andrew Burgess
2026-09-19 11:55 ` Andrew Burgess
2026-09-21  7:51   ` Joos, Christina
2026-09-21 10:04     ` Andrew Burgess [this message]
2026-09-21 13:17       ` Joos, Christina
2026-09-24 13:11         ` Andrew Burgess

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v77yapj3.fsf@redhat.com \
    --to=aburgess@redhat.com \
    --cc=christina.joos@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stephan.rohr@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox