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

[Andrew Burgess <aburgess@redhat.com>]

"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