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
}
}
}
next prev parent 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