Differential D42136
x86: Add a new NT_X86_CPUID regset for ptrace and core dumps Authored by jhb on Oct 9 2023, 4:27 PM. Tags None Referenced Files
Details This is really intended for use in core dumps rather than ptrace (as This could also permit core dumps to use the compact XSAVE format in
Diff Detail
Event TimelineComment Actions This is more of a draft for now as I'm trying to get the same core dump note upstreamed to Linux as well (I have a patch series for GDB that reads this note to determine the layout of the XSAVE regions and that also fixes gcore in GDB to write out the note). For some background, modern AMD and Intel CPUs use different XSAVE layouts. Previously GDB just assumed a single static layout based on Intel's CPUs, but when I replaced my desktop with a Ryzen last year I found that GDB could not parse the XSAVE core dump notes from my desktop. The reason being that my AMD CPU included PKRU and so had an XSAVE layout that extended beyond AVX (including a hole for AVX-512). However, it did not leave a hole for MPX which Intel CPUs have. This meant that the core dumps from AMD didn't match the known size for the XCR0 mask. I've landed changes in GDB (shipping in the next GDB release) to determine the XSAVE layout dynamically for the live process case using CPUID in userland, and to add some heuristics based on XCR0 masks and size to recognize some known cases for core dumps. However, this new core dump note is a more future proof way to allow GDB/LLDB to determine the XSAVE layout in the future. The current note is designed such that we could extend it with more CPUID leaves in the future if they prove useful. Right now GDB just looks for the feature-specific sub-leaves of 0xd to determine the offsets of regions. The information from these sub-leaves could also permit parsing the compact format of XSAVE in the future. (We don't yet use compact XSAVE in our kernel, but Linux uses the compact format internally and expands it back out when writing out process cores and for ptrace().) I made this a new per-thread regset for convenience, but only one copy is actually needed in a core dump. Comment Actions Hmm, I realize I also need to extend gcore(1) to support this note as well which I will do before any commit. Comment Actions Yes. For the Linux kernel side, I have folks from the GDB community (including from Intel and AMD) who will help push that forward. I haven't reached out to anyone at LLDB as of yet and it would be good to get their input. I suspect the thread I'm about to start on the gdb-patches@ mailing list might be the best place to finalize the format, etc. |