This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
On a machine with AVX512 support (AMD EPYC 9634), I see these failures:
$ make check TESTS="gdb.arch/i386-avx512.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
...
FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[16] after writing ZMM regs
FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[17] after writing ZMM regs
FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[18] after writing ZMM regs
...
The problem can be reduced to:
(gdb) print $zmm16.v8_int64
$1 = {0, 0, 0, 0, 0, 0, 0, 0}
(gdb) print $zmm16.v8_int64 = {11,22,33,44,55,66,77,88}
$2 = {11, 22, 33, 44, 55, 66, 77, 88}
(gdb) print $zmm16.v8_int64
$3 = {11, 22, 33, 44, 55, 66, 77, 88}
(gdb) step
5 ++x;
(gdb) print $zmm16.v8_int64
$4 = {11, 22, 77, 88, 0, 0, 0, 0}
Writing to the local regcache in GDB works fine, but the writeback to
gdbserver (which happens when resuming / stepping) doesn't work (the
code being stepped doesn't touch AVX registers, so we don't expect the
value of zmm16 to change when stepping).
The problem is on the gdbserver side, the zmmh and ymmh portions of the
zmm register are not memcpied at the right place in the xsave buffer. Fix
that. Note now how the two modified memcpy calls match the memcmp calls
just above them.
With this patch, gdb.arch/i386-avx512.exp passes completely for me.
Change-Id: I22c417e0f5e88d4bc635a0f08f8817a031c76433
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30818
- Reuse num_xmm_registers directly for the count of ZMM0-15 registers
as is already done for the YMM registers for AVX rather than using
a new variable that is always the same.
- Replace 3 identical variables for the count of upper ZMM16-31
registers with a single variable. Make use of this to merge
various loops working on the ZMM XSAVE region so that all of the
handling for the various sub-registers in this region are always
handled in a single loop.
- While here, fix some bugs in i387_cache_to_xsave where if
X86_XSTATE_ZMM was set on i386 (e.g. a 32-bit process on a 64-bit
kernel), the -1 register nums would wrap around and store the value
of GPRs in the XSAVE area. This should be harmless, but is
definitely odd. Instead, check num_zmm_high_registers directly when
checking X86_XSTATE_ZMM and skip the ZMM region handling entirely if
the register count is 0.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Replace the extended state area fields of i387_xsave with methods which
return an offset into the XSAVE buffer.
The two changed functions are called within all tests which runs
gdbserver.
Signed-off-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Co-authored-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Legacy fields of the XSAVE area are already defined within fx_save
struct. Use class inheritance to remove code duplication.
The two changed functions are called within all tests which run
gdbserver.
Signed-off-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Co-authored-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Make x86_xcr0 private to i387-fp.cc and use i387_set_xsave_mask to set
the value instead. Add a static global instance of x86_xsave_layout
and initialize it in the new function as well to be used in a future
commit to parse XSAVE extended state regions.
Update the Linux port to use this function rather than setting
x86_xcr0 directly. In the case that XML is not supported, don't
bother setting x86_xcr0 to the default value but just omit the call to
i387_set_xsave_mask as i387-fp.cc defaults to the SSE case used for
non-XML.
In addition, use x86_xsave_length to determine the size of the XSAVE
register set via CPUID.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
PR27257 reports a problem that can be reproduced as follows:
- use x86_64 machine with avx512 support
- compile a hello world with -m32 to a.out
- start a gdbserver session with a.out
- use gdb to connect to the gdbserver session
This makes us run into:
...
Listening on port 2346
Remote debugging from host ::1, port 34940
src/gdbserver/regcache.cc:257: \
A problem internal to GDBserver has been detected.
Unknown register zmm16h requested
...
The problem is that i387_xsave_to_cache in gdbserver/i387-fp.cc can't find a
register zmm16h in the register cache.
To understand how this happens, first some background.
SSE has 16 128-bit wide xmm registers.
AVX extends the SSE registers set as follows:
- it extends the 16 existing 128-bit wide xmm registers to 256-bit wide ymm
registers.
AVX512 extends the AVX register set as follows:
- it extends the 16 existing 256-bit wide ymm registers to 512-bit wide zmm
registers.
- it adds 16 additional 512-bit wide zmm registers (with corresponding ymm and
xmm subregisters added as well)
However, in 32-bit mode, there are only 8 xmm/ymm/zmm registers.
The problem we're running into is that gdbserver/i387-fp.cc uses these
constants to describe the size of the register file:
...
static const int num_avx512_zmmh_low_registers = 16;
static const int num_avx512_zmmh_high_registers = 16;
static const int num_avx512_ymmh_registers = 16;
static const int num_avx512_xmm_registers = 16;
...
which are all incorrect for the 32-bit case.
Fix this by replacing the constants with variables that have the appropriate
values in 64-bit and 32-bit mode.
Tested on x86_64-linux with native and unix/-m32.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
For the same reasons outlined in the previous patch, this patch renames
gdbserver source files to .cc.
I have moved the "-x c++" switch to only those rules that require it.
gdbserver/ChangeLog:
* Makefile.in: Rename source files from .c to .cc.
* %.c: Rename to %.cc.
* configure.ac: Rename server.c to server.cc.
* configure: Re-generate.
