When running test-case gdb.arch/i386-avx512.exp, I run into:
...
gdb compile failed, In file included from gdb.arch/i386-avx512.c:20:0:
src/gdb/nat/x86-cpuid.h: In function 'x86_cpuid_count':
src/gdb/nat/x86-cpuid.h:63:16: error: \
'nullptr' undeclared (first use in this function)
if (__eax == nullptr)
^~~~~~~
src/gdb/nat/x86-cpuid.h:63:16: note: each \
undeclared identifier is reported only once for each function it appears in
=== gdb Summary ===
# of untested testcases 1
...
This is due to commit e85aad4ae7 ("nat/x86-cpuid.h: Add x86_cpuid_count
wrapper around __get_cpuid_count"), which introduced the nullptr check.
The header file gdb/nat/x86-cpuid.h is a file that is included in the build
and compiled as a C++ file, but also in the testsuite and compiled as a C
file.
Fix this by replacing nullptr with (void *)0.
Tested on x86_64-linux.
Co-Authored-By: Kevin Buettner <kevinb@redhat.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>
array_operation::evaluate has variables named "tem2" and "tem3". This
patch replaces one with a better name, and entirely removes the other.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
value_array requires the passed-in bounds to match the length of the
array_view it is given. This patch removes the redundant "highbound"
parameter.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This removes yet another redundant variable from
array_operation::evaluate -- only one index is needed.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In array_operation::evaluate, 'idx' and 'tem' are redundant in one
branch. This patch merges them, using the clearer name.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This hoists the array bounds check in array_operation::evaluate to
before the loop.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes array_operation::evaluate to declare the 'tem' variable
in the loop header, rather than at the top of the function. This is
cleaner and easier to reason about. I also changed 'nargs' to be
'const'.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This changes value_array to accept an array view. I also replaced an
alloca with a std::vector in array_operation::evaluate. This function
can work on any size of array, so it seems bad to use alloca.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When running this test on a processor that supports AVX512 (AMD EPYC
9634) on Debian 12 bookwork (system compiler is gcc 12.2.0), I see:
continue^M
Continuing.^M
Process record does not support instruction bound.^M
Process record does not support instruction 0x62 at address 0x7ffff7f49b40.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff7f49b40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main
The instruction at this address is:
0x00007ffff7f49b40: 62 e2 7d 48 7a c6 vpbroadcastb %esi,%zmm16
This seems like an AVX512 instruction (given the use of zmm16). Match
this byte value in order to produce a KFAIL.
Change-Id: I1d20357fa538ba60b9c537160acf511a37d751ee
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30807
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.arch/i386-avx512.exp with gcc 4.8.4, I run into:
...
Running gdb.arch/i386-avx512.exp ...
gdb compile failed, gcc: error: unrecognized command line option '-mavx512f'
...
Fix this by requiring have_compile_flag -mavx512f.
Tested on x86_64-linux.
When running test-case gdb.linespec/cpls-abi-tag.exp with gcc 4.8.4, we run
into:
...
cpls-abi-tag.cc:71:26: error: ‘abi_tag’ attribute applied to non-function ‘s’
ABI3 test_abi_tag_struct s;
^
...
The test-case is supported starting gcc 5.
Fix this by requiring gcc >= 5, if a gcc compiler is used.
Tested on x86_64-linux.
When running test-case gdb.mi/print-simple-values.exp with gcc 4.8.4, I run
into a compilation failure due to the test-case requiring c++11 and the
compiler defaulting to less than that.
Fix this by compiling with -std=c++11.
Likewise in a few other test-cases.
Tested on x86_64-linux.
In test-case gdb.tui/pr30056.exp we check for:
...
require {have_host_locale C.UTF-8}
...
The "C.UTF-8" is normalized by have_host_locale to "c.utf8", before trying to
find it in the list returned by host_locales.
On my development platform, "locale -a" lists C.utf8, which is normalized to
"c.utf8" by host_locales, so there's a match and have_host_locale returns true.
On another platform however, "locale -a" lists C.UTF-8, which is normalized to
"c.utf-8" by host_locales, so there's no match and have_host_locale returns false.
Fix this by also dropping the dash in host_locales.
Tested on x86_64-linux.
This patch changes remote.c so that the getpkt 'forever' parameter now
defaults to 'false' and fixes up all the callers.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
getpkt and getpkt_or_notif_sane are just wrappers for
getpkt_or_notif_sane_1. This patch adds the is_notif parameter to
getpkt, with a suitable default, and removes the wrappers.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
For getpkt_or_notif_sane_1, expecting_notif is redundant, because it
always reflects whether the is_notif parameter is non-NULL. This
patch removes the redundant parameter.
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
When running test-case gdb.reverse/getrandom.exp on a system with eglibc 2.19,
we run into:
...
gdb compile failed, gdb.reverse/getrandom.c:18:24: fatal error: \
sys/random.h: No such file or directory
#include <sys/random.h>
^
compilation terminated.
=== gdb Summary ===
# of untested testcases 1
...
and:
...
UNTESTED: gdb.reverse/getrandom.exp: failed to prepare
...
Fix this by testing for the presence of the header, such that we have instead:
...
UNSUPPORTED: gdb.reverse/getrandom.exp: require failed: \
have_system_header sys/random.h
...
Tested on x86_64-linux and i686-linux.
In test-case gdb.cp/nsusing.exp I came across these xfails without PRMS
mentioned:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement
XFAIL: gdb.cp/nsusing.exp: print x, only using M
...
Add the missing PRMS, such that we have:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement (PRMS gcc/108716)
XFAIL: gdb.cp/nsusing.exp: print x, only using M (PRMS gcc/108716)
...
and limit the xfail to unfixed versions.
The PR is fixed starting gcc 13, but it has been backported to release
branches stretching back to gcc 10. For simplicity we just stick to testing
for the major version and ignore the backported fixes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
- 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>
All of the tables describing the offsets of individual registers for
XSAVE state components now hold relative offsets rather than absolute
offsets. Some tables (those for MPX registers and ZMMH registers) had
to be split into separate tables as they held entries that spanned
multiple state components.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Note that this uses the CPUID instruction to determine the total size
of the XSAVE register set. If there is a way to fetch the register set
size using ptrace that would probably be better.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Refactor i386_linux_core_read_xcr0 to fetch and return a corresponding
x86_xsave_layout as well as xcr0 using the size of an existing
NT_X86_XSTATE core dump to determine the offsets via
i387_guess_xsave_layout. Use this to add an implementation of
gdbarch_core_xfer_x86_xsave_layout.
Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
set.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Refactor i386fbsd_core_read_xcr0 to fetch and return a corresponding
x86_xsave_layout as well as xcr0 using the size of an existing
NT_X86_XSTATE core dump to determine the offsets via
i387_guess_xsave_layout. Use this to add an implementation of
gdbarch_core_xfer_x86_xsave_layout.
Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
set and only fetch/store the register set if this size is non-zero.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
x86_xsave_length returns the total length of the XSAVE state area
standard format as queried from CPUID.
x86_fetch_xsave_layout uses CPUID to query the offsets of XSAVE
extended regions from the running host. The total length of the XSAVE
state area can either be supplied by the caller if known (e.g. from
FreeBSD's PT_GETXSTATEINFO) or it can be queried from the running host
using x86_xsave_length.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Add gdbarch_core_read_x86_xsave_layout to fetch the x86 XSAVE layout
structure from a core file.
Current OS's do not export the offsets of XSAVE state components in
core dumps, so provide an i387_guess_xsave_layout helper function to
set offsets based on known combinations of XCR0 masks and total state
sizes. Eventually when core dumps do contain this information this
function should only be used as a fall back for older core dumps.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This structure is fetched from the current target in i386_gdbarch_init
via a new "fetch_x86_xsave_layout" target method.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
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>
Mark Wielaard pointed out that cooked_index::dump uses PRIx64, and
Andreas Schwab pointed out that gdb already has sect_offset_str. This
patch applies both these observations.
The getsymname function uses PRIxPTR to print and uintptr_t value in
an error message. Use hex_string instead.
Approved-By: Tom Tromey <tom@tromey.com>
Building gdb with gcc 7.5.0 and -flto -O2 -flto-partition=one generates a
self-referencing DIE:
...
<2><91dace>: Abbrev Number: 405 (DW_TAG_label)
<91dad0> DW_AT_abstract_origin: <0x91dace>
...
When encountering the self-reference DIE in inherit_abstract_dies we loop
following the abstract origin, effectively hanging gdb.
Fix this by handling self-referencing DIEs in the loop in
inherit_abstract_dies.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30799
https://sourceware.org/bugzilla/show_bug.cgi?id=30799
A low level function like coff_swap_aux_in really has no business
concatenating multiple auxents for the old PE multi-aux scheme of
handling long file names. In doing so, it assumes multiple internal
auxent buffers are available, which they are not in most calls to
bfd_coff_swap_aux_in, both inside BFD and outside, eg. GDB. Buffer
overflow fun. Concatenating multiple auxents belongs at a higher
level.
This required some changes to coff_get_normalized_symtab, which now
uses the external auxents to access the concatenated file name.
(Internal auxents are larger than the x_fname array, so the pieces of
the file name are not adjacent as they are in the external auxents.)
* coffswap.h (coff_swap_aux_in): Do not write more than one
internal auxent.
* coffcode.h (coff_bigobj_swap_aux_in): Likewise.
* coffgen.c (coff_get_normalized_symtab): Normalize strings
after swapping in each symbol so that external auxents are
available. Use external auxents for multi-aux long file
names. Formatting. Wrap long lines. Remove excess parens
and unnecessary casts. Don't zalloc when only the string
terminator needs zeroing, and memcpy rather than strncpy.
Delete unnecessary sanity check with unsigned _n_offset.
Return with failure if debug section can't be read, to avoid
trying to read it multiple times. Correct sanity check
against debug section size.
I missed another field that needs freeing. Also, oss-fuzz found a
case with a C_FILE sym using multiple auxents for a long file name
which overflowed the single auxent buffer. I'm going to fix that
problem in swap_aux_in too, but we may as well avoid it here too,
saving unnecessary work.
* coffcode.h (comdat_delf): Free comdat_name.
(fill_comdat_hash): Only look at symbols with one auxent.
When running test-cases gdb.cp/*.exp with gcc 4.8.4, I run into compilation
failures due to the test-cases requiring c++11 and the compiler defaulting
to less than that.
Fix this by compiling with -std=c++11.
This exposes two FAILs in gdb/testsuite/gdb.cp/empty-enum.exp due to
gcc PR debug/16063, so xfail those.
Also require have_compile_flag -std=c++17 in gdb.cp/constexpr-field.exp to
prevent compilation failure.
Tested on x86_64-linux.
Following the arrangement in GCC select a 64-bit ABI by default, either
n32 or n64, rather than o32 for `mipsisa64*-*-linux*' targets, just as
with the corresponding `mips64*-*-linux*' targets.
