John Baldwin
d39b60f2e0
The standard layout of the XSAVE extended state area consists of three regions. The first 512 bytes (legacy region) match the layout of the FXSAVE instruction including floating point registers, MMX registers, and SSE registers. The next 64 bytes (XSAVE header) contains a header with a fixed layout. The final region (extended region) contains zero or more optional state components. Examples of these include the upper 128 bits of YMM registers for AVX. These optional state components generally have an architecturally-fixed size, but they are not assigned architectural offsets in the extended region. Instead, processors provide additional CPUID leafs describing the size and offset of each component in the "standard" layout for a given CPU. (There is also a "compact" format which uses an alternate layout, but existing OS's currently export the "standard" layout when exporting XSAVE data via ptrace() and core dumps.) To date, GDB has assumed the layout used on current Intel processors for state components in the extended region and hardcoded those offsets in the tables in i387-tdep.c and i387-fp.cc. However, this fails on recent AMD processors which use a different layout. Specifically, AMD Zen3 and later processors do not leave space for the MPX register set in between the AVX and AVX512 register sets. To rectify this, add an x86_xsave_layout structure which contains the total size of the XSAVE extended state area as well as the offset of each known optional state component. Subsequent commits will modify XSAVE parsing in both gdb and gdbserver to use x86_xsave_layout. Co-authored-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.