On 3/14/24 04:23, Vignesh Balasubramanian wrote: > Add a new .note section containing type, size, offset and flags of > every xfeature that is present. Mechanically, I'd much rather have all of that info in the cover letter in the actual changelog instead. I'd also love to see a practical example of what an actual example core dump looks like on two conflicting systems: * Total XSAVE size * XCR0 value * XSTATE_BV from the core dump * XFEATURE offsets for each feature Do you have any information about what other OSes are doing in this area? I thought Windows, for instance, was even less flexible about the XSAVE format than Linux is. Why didn't LWP cause this problem? >From the cover letter: > But this patch series depends on heuristics based on the total XSAVE > register set size and the XCR0 mask to infer the layouts of the > various register blocks for core dumps, and hence, is not a foolproof > mechanism to determine the layout of the XSAVE area. It may not be theoretically foolproof. But I'm struggling to think of a case where it would matter in practice. Is there any CPU from any vendor where this is actually _needed_? Sure, it's ugly as hell, but these notes aren't going to be available universally _ever_, so it's not like the crummy heuristic code gets to go away. Have you seen the APX spec? > https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html It makes this even more fun because it adds a new XSAVE state component, but reuses the MPX offsets. > This information will be used by the debuggers to understand the XSAVE > layout of the machine where the core file is dumped, and to read XSAVE > registers, especially during cross-platform debugging. This is pretty close to just a raw dump of the XSAVE CPUID leaves. Rather than come up with an XSAVE-specific ABI that depends on CPUID *ANYWAY* (because it dumps the "flags" register aka. ECX), maybe we should just bite the bullet and dump out (some of) the raw CPUID space.
