A year or so ago I purchased a new desktop with an AMD Ryzen CPU and discovered that GDB did not like the NT_X86_XSTATE register notes in core dumps on FreeBSD. These notes used a size that GDB did not understand. Current releases of GDB have assumed a fixed layout of the extended regions of the XSAVE area (basically following the layout of Intel CPUs to date). However, my Ryzen CPU used a different layout. It included PKRU, but it did not leave a gap for the MPX regions in its XSAVE layout, just a gap for AVX-512 between AVX and PKRU.
As a first level workaround, I wrote a series of patches for GDB to add a notion of an XSAVE layout with a variable starting offset for each of the extended state regions (e.g. AVX, PKRU, the various AVX-512 regions). For a live process CPUID on the host is queried to determine the layout returned by ptrace(). However, for a core dump, GDB currently uses a heuristic based on the active XCR0 mask and the register note size to infer a layout ([PATCH v6 00/15] Handle variable XSAVE layouts is the cover letter for the last version of that patch series).
The heuristic is fragile however, and as a more permanent fix, I have proposed adding a new core dump note (with patches for GDB and FreeBSD’s kernel) to dump the relevant leaves of CPUID so that GDB can use that to determine the XSAVE layout reliably. That proposal (and set of patches to GDB) can be found at [PATCH v6 00/15] Handle variable XSAVE layouts with the FreeBSD kernel patch (still in review) at ⚙ D42136 x86: Add a new NT_X86_CPUID regset for ptrace and core dumps.
Folks from AMD have helpfully offered to work on adding support to the Linux kernel upstream and are cc’d on the thread on gdb-patches@. However, I wanted to loop the LLDB folks if you have any input. Given that there is already some active discussion on the gdb-patches@ thread, I believe that might be the best place to coordinate discussion on this idea, but I’ll watch for any followups here as well.