The intention of this code seems to be to indicate that this insn
should not be used and produces undefined behavior, so instead of
setting registers to bogus values, call Unpredictable. This fixes
build warnings due to 32-bit/64-bit type conversions, and outputs
a log message for users at runtime instead of silent corruption.
Bug: https://sourceware.org/PR29276
This hasn't been used by gdb in decades, and doesn't make sense with
a standalone sim program/library where the ABI is fixed. So punt it
to simplify the code.
Hi all,
This wrong comment was introduced by previous AVX-VNNI-INT8 commit.
Committed as obvious fix.
BRs,
Haochen
opcodes/ChangeLog:
* i386-dis.c (VEX_W_0F3851): Corrected from
VEX_W_0F3851_P_0.
The switch to linking with libtool now shows a very long link line
even when V=0. This patch arranges to silence libtool in this
situation.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 64. We
can easily move this into the makefile via a -D compiler flag and
clean up the build logic quite a bit.
We've been using this only to set the default word size to 32-vs-64
based on the $target. We can easily merge this with the top-level
configure script to clean things up a bit.
This patch changes the GDB build system in order to use libtool to
link the several built executables. This makes it possible to refer
to libtool libraries (.la files) in CLIBS.
As an application of the above,
BFD now refers to ../libbfd/libbfd.la
OPCODES now refers to ../opcodes/libopcodes.la
LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
LIBCTF now refers to ../libctf/libctf.la
NOTE1: The addition of libtool adds a few new configure-time options
to GDB. Among these, --enable-shared and --disable-shared, which were
previously ignored. Now GDB shall honor these options when linking,
picking up the right version of the referred libtool libraries
automagically.
NOTE2: I have not tested the insight build.
NOTE3: For regenerating configure I used an environment with Autoconf
2.69 and Automake 1.15.1. This should match the previously
used version as announced in the configure script.
NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and
libctf.so are used by gdb if binutils is installed with
--enable-shared.
Testing performed:
- --enable-shared and --disable-shared (the default in binutils) work
as expected: the linked executables link with the archive or shared
libraries transparently.
- Makefile.in modified for EXEEXT = .exe. It installs the binaries
just fine. The installed gdb.exe runs fine.
- Native build regtested in x86_64. No regressions found.
- Cross build for aarch64-linux-gnu built to exercise
program_transform_name and friends. The installed
aarch64-linux-gnu-gdb runs fine.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29372
Approved-By: Simon Marchi <simon.marchi@efficios.com>
I see failures in this test, due to the function name "add" being too
generic, and unexpected breakpoint locations being found in my
libstdc++, such as (wrapped for readability):
{
number="2.4",enabled="y",addr="0x00007ffff7d67e68",
func="(anonymous namespace)::fast_float::bigint::add",
file="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
fullname="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
line="1815", thread-groups=["i1"]
}
Change the test to use a more unique name.
Change-Id: I91de781be62d246eb41c73eaa410ebdd12633d1d
linux_handle_extended_wait calls target_post_attach if we're handling
a PTRACE_EVENT_CLONE, and libthread_db.so isn't active.
target_post_attach just calls linux_init_ptrace_procfs to set the
lwp's ptrace options. However, this is completely unnecessary,
because, as man ptrace [1] says, options are inherited:
"Flags are inherited by new tracees created and "auto-attached" via
active PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
options."
This removes the unnecessary call.
[1] - https://man7.org/linux/man-pages/man2/ptrace.2.html
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I533eaa60b700f7e40760311fc0d344d0b3f19a78
The install code was using $SUBDIRS to track all enabled arches. This
works, but isn't great if we want to add a subdir that isn't an arch
port, or as we merge the subdirs into the top-level. Create a new var
explicitly to track the list of enabled arches instead.
gas uses ZSTD_compressStream2 which is only available with libzstd >=
1.4.0, leading to build errors when an older version is installed.
This patch updates the check libzstd presence to check its version is
>= 1.4.0. However, since gas seems to be the only component requiring
such a recent version this may imply that we disable ZSTD support for
all components although some would still benefit from an older
version.
I ran 'autoreconf -f' in all directories containing a configure.ac
file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
several errors from autoheader in readline, as well as warnings in
intl, but they are unrelated to this patch.
This should fix some of the buildbots.
OK for trunk?
Thanks,
Christophe
Call the helper function "check_shared_lib_support" to ensure -shared
is enabled before launching ld-shared, ld-elfweak and ld-elfvers.
This allows to catch custom targets explicitly disabling it.
ld/ChangeLog:
* testsuite/ld-elfvers/vers.exp: Call check_shared_lib_support.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.
Despite that the RISC-V ISA Manual version 2.2 prohibited "RV32EF", later
versions beginning with the version 20190608-Base-Ratified removed this
restriction. Because the 'E' extension is still a draft, the author chose
to *just* remove the conflict (not checking the ISA version).
Note that, because RV32E is only used with a soft-float calling convention,
there's no valid official ABI for RV32EF. It means, even if we can assemble
a program with -march=rv32ef -mabi=ilp32e, floating-point registers are kept
in an unmanaged state (outside ABI management).
The purpose of this commit is to suppress unnecessary errors while parsing
an ISA string and/or disassembling, not to allow hard-float with RVE.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts): Accept RV32EF
because only older specifications disallowed it.
gas/ChangeLog:
* testsuite/gas/riscv/march-fail-rv32ef.d: Remove as not directly
prohibited.
* testsuite/gas/riscv/march-fail-rv32ef.l: Likewise.
This was needed when the install step was run in subdirs, but now
that we process that entirely in the top-level, we don't need to
pass this down, so drop it.
MI version 1 is long since obsolete. Rather than remove it
immediately (though I did send a patch for that), instead let's
deprecate it in GDB 13 and then remove it for GDB 14.
This version of the patch incorporates Simon's warning change, and
Luis' recommendation to mention the gdb versions here.
Automake will run each subdir individually before moving on to the next
one. This means that the linking phase, a single threaded process, will
not run in parallel with anything else. When we have to link ~32 ports,
that's 32 link steps that don't take advantage of parallel systems. On
my really old 4-core system, this cuts a multi-target build from ~60 sec
to ~30 sec. We eventually want to move all compile+link steps to this
common dir anyways, so might as well move linking now for a nice speedup.
We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care
of the install ourselves rather than letting automake process it.
We still have to maintain custom install rules due to how we rename
arch-specific files with an arch prefix in their name, but we can at
least unify the logic in the common dir.
Nothing in the tree checks this option, or has checked for decades.
The pre-cvs-import ChangeLog suggests this was added & removed back
then, but can't be sure as that history doesn't exist in the VCS.
Nothing checks this define anywhere, so drop all the logic. We don't
want this to be a configure option in the first place as all such usage
should be automatic & following proper types.
This has only ever had a single option that's enabled by default.
The objects it adds are pretty small and don't add overhead at
runtime if it isn't used, so just enable it all the time to make
the build code simpler.
Update expected PR binutils/26160 test output for readelf out change
and run PR binutils/26160 test.
PR binutils/26160
* testsuite/binutils-all/pr26160.r: Updated.
* testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test.
One test name in gdb.base/dlmopen.exp changes from run to run
since it includes a process id:
PASS: gdb.base/dlmopen.exp: attach 3442682
This is not convenient do diff gdb.sum files to compare test runs.
Fix by using gdb_attach helper function to handle attaching to the
process as it produce a constant test name.
While at it also check gdb_attach's return value to only run the
rest of the test if the attach was successful.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, and pmxvi16ger2* instructions were officially changed to
pmdmxbf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively. The old mnemonics are still supported by the
assembler as extended mnemonics. The disassembler generates the new
mnemonics. The name changes occurred in commit:
commit bb98553cad
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Sat Oct 8 16:19:51 2022 -0500
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
opcodes/
* ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
(powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
This patch updates the comments in the various gdb files to reflect the
name changes. There are no functional changes made by this patch.
The older instruction names are still used in the test
gdb.reverse/ppc_record_test_isa_3_1.exp for backwards compatibility.
Patch has been tested on Power 10 with no regressions.
The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, pmxvi16ger2* instructions were officially changed to
pmdmxvf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively. The old mnemonics are still supported by the
assembler as extended mnemonics. The disassembler generates the new
mnemonics. The name changes occurred in commit:
commit bb98553cad
Author: Peter Bergner <bergner@linux.ibm.com>
Date: Sat Oct 8 16:19:51 2022 -0500
PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions
gas/
* config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
* testsuite/gas/ppc/rfc02658.s: New test.
* testsuite/gas/ppc/rfc02658.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
opcodes/
* ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
(powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.
The above commit results in about 224 failures on Power 10 since the
disassembled names do not match the expected names in the test. This
patch updates the expected names in the test to match the values produced
by the disassembler.
This patch updates file gdb.arch/powerpc-power10.exp with the new expected
values to the instructions. The comment giving the name of the instruction
for each binary value in the file gdb.arch/powerpc-power10.c is updated
with the new name. There are no functional changes in file
gdb.arch/powerpc-power10.c.
The test disassembles function foo and searches for the line
"End of assembler dump" to determing the last address in the function. The
assumption is the last instruction will be given right before the line
"End of assembler dump". This assumption fails on PowerPC.
The PowerPC disassembly of the function foo looks like:
Dump of assembler code for function foo:
# => 0x00000000100006dc <+0>: std r31,-8(r1)
# 0x00000000100006e0 <+4>: stdu r1,-48(r1)
# 0x00000000100006e4 <+8>: mr r31,r1
# 0x00000000100006e8 <+12>: nop
# 0x00000000100006ec <+16>: addi r1,r31,48
# 0x00000000100006f0 <+20>: ld r31,-8(r1)
# 0x00000000100006f4 <+24>: blr
# 0x00000000100006f8 <+28>: .long 0x0
# 0x00000000100006fc <+32>: .long 0x0
# 0x0000000010000700 <+36>: .long 0x1000180
# End of assembler dump.
The blr instruction is the last instruction in function foo. The lines
with .long following the blr instruction need to be ignored.
This patch adds a new condition to the gdb_test_multiple "disassemble foo"
test to ignore the lines with the .long.
The patch has been tested on PowerPC and Intel X86-64.
Recent changes to gdb.reverse/step-reverse.exp revealed the latent bug
PR record/29745, where we can't skip one funcion forward if we're using
native-gdbserver. This commit just adds kfails to the test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29745
Approved-By: Simon Marchi <simon.marchi@efficios.com>
After this commit:
commit 6576bffe6c
Date: Thu Jul 7 13:43:45 2022 +0100
opcodes/arm: add disassembler styling for arm
Some people were seeing their builds failing with complaints about a
possible uninitialized variable usage. I previously fixed an instance
of this issue in this commit:
commit 2df82cd4b4
Date: Tue Nov 1 10:36:59 2022 +0000
opcodes/arm: silence compiler warning about uninitialized variable use
which did fix the build problems that the sourceware buildbot was
hitting, however, an additional instance of the same problem was
brought to my attention, and that is fixed in this commit.
Where commit 2df82cd4b4 fixed the uninitialized variable problem in
print_mve_unpredictable, this commit fixes the same problem in
print_mve_undefined.
As with the previous commit, I don't believe we could really ever get
an uninitialized variable usage, based on the current usage of the
function, so I have just initialized the reason variable to "??".
