Re: [PATCH v4 12/13] gdbserver: Read offsets of the XSAVE extended region via CPUID

[John Baldwin <jhb@FreeBSD.org>]

On 4/11/23 7:46 AM, Pedro Alves wrote:
> On 2023-03-18 1:09 a.m., John Baldwin wrote:
> 
>> SDM recommends to obtain memory offsets values only by calling CPUID
>> because they can change depending on the CPU mode.
> 
> I'm not sure what this sentence is saying -- only by calling CPUID, as
> opposed to doing what instead?  Is this saying that consulting CPUID
> for the host (the machine running gdbserver in this case) returns the correct
> result even if gdbserver is 64 bit, and the inferior is 32 bit, but that
> with some other method (but which?) it wouldn't?

Humm, I hadn't reworded Aleksandar's message, but I should perhaps clarify
this part.  I think the layout of XSAVE does not change between 32-bit
and 64-bit inferiors while you are in long mode (and for most (all relevant?) OS's
you are doing the XSAVE in the kernel which is always 64-bit).  I do think
that in theory the layout might change based on the enabled mask in XCR0.
Certainly the "compact" layout (which OS's currently do not expose to debuggers)
changes based on the XCR0 layout (right now FreeBSD doesn't use the cmopact
format in the kernel, and Linux is careful to expand the "compact" format
out to the "standard" format when exporting XSAVE state as a register set
for ptrace and core dumps).

Also, I think the alternative to doing CPUID is what GDB does today which
is to have a set of hard-coded constants describing the starting offset of
each region in the extended save area.

-- 
John Baldwin