Setting the milestone to 14.1 as per Simon's request (regression).

FTR, marked as IN for 14.1 because it's a regression from GDB 13.

Hi Simon,

Do you know if anyone is working on this PR? John (author of the patch you identified below) maybe? For the GDB 14.1 release, I'm hoping that we can publish it during the weekend of Nov 18-19, and since this one is a regression that we are trying to fix in 14.1, it would be nice to confirm whether someone is on it or not. If not, we may decide to skip it for 14.1 and perhaps aim for 14.2 instead.

Thank you!

IIRC, this failure was introduced with the XSAVE work, but I don't remember the specifics of why the test passed before and it doesn't now.  It's likely related to the fact that we don't have a way for GDB to get the CPUID information from GDBserver (John can confirm).

Looking at the failure a bit more in details, when doing "info all-reg" we expect this (I only included ymm0 for brevity, but it's ymm0 to ymm15):

ymm0           {v16_bfloat16 = {0xc300, 0xf7e9, 0x7fff, 0x0, 0xc300, 0xf7e9, 0x7fff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v16_half = {0xc300, 0xf7e9, 0x7fff, 0x0, 0xc300, 0xf7e9, 0x7fff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_float = {0xf7e9c300, 0x7fff, 0xf7e9c300, 0x7fff, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x7ffff7e9c300, 0x7ffff7e9c300, 0x0, 0x0}, v32_int8 = {0x0, 0xc3, 0xe9, 0xf7, 0xff, 0x7f, 0x0, 0x0, 0x0, 0xc3, 0xe9, 0xf7, 0xff, 0x7f, 0x0 <repeats 18 times>}, v16_int16 = {0xc300, 0xf7e9, 0x7fff, 0x0, 0xc300, 0xf7e9, 0x7fff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v8_int32 = {0xf7e9c300, 0x7fff, 0xf7e9c300, 0x7fff, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x7ffff7e9c300, 0x7ffff7e9c300, 0x0, 0x0}, v2_int128 = {0x7ffff7e9c30000007ffff7e9c300, 0x0}}

but get:

ymm0           {v16_bfloat16 = {0xc300, 0xf7e9, 0x7fff, 0x0, 0xc300, 0xf7e9, 0x7fff, 0x0, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>}, v16_half = {0xc300, 0xf7e9, 0x7fff, 0x0, 0xc300, 0xf7e9, 0x7fff, 0x0, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>}, v8_float = {0xf7e9c300, 0x7fff, 0xf7e9c300, 0x7fff, <unavailable>, <unavailable>, <unavailable>, <unavailable>}, v4_double = {0x7ffff7e9c300, 0x7ffff7e9c300, <unavailable>, <unavailable>}, v32_int8 = {0x0, 0xc3, 0xe9, 0xf7, 0xff, 0x7f, 0x0, 0x0, 0x0, 0xc3, 0xe9, 0xf7, 0xff, 0x7f, 0x0, 0x0, <unavailable> <repeats 16 times>}, v16_int16 = {0xc300, 0xf7e9, 0x7fff, 0x0, 0xc300, 0xf7e9, 0x7fff, 0x0, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>, <unavailable>}, v8_int32 = {0xf7e9c300, 0x7fff, 0xf7e9c300, 0x7fff, <unavailable>, <unavailable>, <unavailable>, <unavailable>}, v4_int64 = {0x7ffff7e9c300, 0x7ffff7e9c300, <unavailable>, <unavailable>}, v2_int128 = {0x7ffff7e9c30000007ffff7e9c300, <unavailable>}}

Sorry I didn't see this earlier for some reason, yes, this is related to the fact that when using gdbserver, GDB doesn't know what layout to use when writing out a core dump.

The long term solution is to pull the CPUID info from gdbserver in the form of NT_X86_CPUID, but in the short term we could just always use the Intel layout that GDB assumed before the XSAVE series.  That is, we could pick a default layout based on the XCR0 mask that corresponds to one of the known sizes and use that to set both the layout and size.  I'll see if I can't come up with a variant of that today or tomorrow.

The master branch has been updated by John Baldwin <jhb@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=66637e209cc836c19a21a28e91046649c7702037

commit 66637e209cc836c19a21a28e91046649c7702037
Author: John Baldwin <jhb@FreeBSD.org>
Date:   Mon Nov 27 13:53:22 2023 -0800

    i386: Use a fallback XSAVE layout for remote targets
    
    If a target provides a target description including registers from the
    XSAVE extended region, but does not provide an XSAVE layout, use a
    fallback XSAVE layout based on the included registers.  This fallback
    layout matches GDB's behavior in earlier releases which assumes the
    layout from Intel CPUs.
    
    This fallback layout is currently only used for remote targets since
    native targets which support XSAVE provide an explicit layout derived
    from CPUID.
    
    PR gdb/30912
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912
    Approved-By: Simon Marchi <simon.marchi@efficios.com>

The gdb-14-branch branch has been updated by John Baldwin <jhb@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=823c11ef481acd1b1e768302e702ae998cc1de70

commit 823c11ef481acd1b1e768302e702ae998cc1de70
Author: John Baldwin <jhb@FreeBSD.org>
Date:   Mon Nov 27 13:53:22 2023 -0800

    i386: Use a fallback XSAVE layout for remote targets
    
    If a target provides a target description including registers from the
    XSAVE extended region, but does not provide an XSAVE layout, use a
    fallback XSAVE layout based on the included registers.  This fallback
    layout matches GDB's behavior in earlier releases which assumes the
    layout from Intel CPUs.
    
    This fallback layout is currently only used for remote targets since
    native targets which support XSAVE provide an explicit layout derived
    from CPUID.
    
    PR gdb/30912
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912
    Approved-By: Simon Marchi <simon.marchi@efficios.com>
    
    (cherry picked from commit 66637e209cc836c19a21a28e91046649c7702037)

Fix merged to master and gdb-14-branch.