From: "Joos, Christina" <christina.joos@intel.com>
To: Andrew Burgess <aburgess@redhat.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 13:17:54 +0000 [thread overview]
Message-ID: <SN7PR11MB7638A3BA361BA4303B9D2EF089842@SN7PR11MB7638.namprd11.prod.outlook.com> (raw)
In-Reply-To: <87v77yapj3.fsf@redhat.com>
> -----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.
next prev parent reply other threads:[~2026-09-21 13:18 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
2026-09-21 13:17 ` Joos, Christina [this message]
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=SN7PR11MB7638A3BA361BA4303B9D2EF089842@SN7PR11MB7638.namprd11.prod.outlook.com \
--to=christina.joos@intel.com \
--cc=aburgess@redhat.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