Thanks to Jakub Jelinek. The test is broken. It blindly assumes the
toplevel inline asm is placed into some sensible section, but that is
a wrong assumption. The right thing is to start the inline asm with
.text directive and end with .previous. The reason gcc 10 breaks it
is the -fno-common default, the int r1, ... vars are emitted into .bss
section and that is the section that is current when the inline asm is
emitted previously they were in .common at the end of the assembly file.
Guard withinEpsOf[FD] within none/tests/mips32/msa_fpu.c
Enclose the recently introduced functions with preprocessor guards,
much like the rest of the code is inside the main function.
Also mark the functions as static.
Minor code formatting.
Change the math tests to check whether the results are approximate to the
expected values instead of checking for exact matches since the calculations
in question are allowed to be approximate.
This fixes
/none/tests/mips64/test_math and
/none/tests/mips64/msa_fpu
on mips64r6.
* removes --vex-guest-chase-cond=no|yes. This was never used in practice.
* rename --vex-guest-chase-thresh=<0..99> to --vex-guest-chase=no|yes. In
otherwords, downgrade it from a numeric flag to a boolean one, that can
simply disable all chasing if required. (Some tools, notably Callgrind,
force-disable block chasing, so this functionality at least needs to be
retained).
The estimate instructions (rcpss, rcpps, rsqrtps, rsqrtss) are, as the
name suggests, not expected to give a fully accurate result. They may
produce slighly different results on different CPU families because
their results are not defined by the IEEE standard. This is the
reason avx-1 test fails on amd now.
This patch assumes there are only two implementations, the intel and
amd one. It moves these estimate instructions out of avx-1 and into
their own testcase - avx_estimate_insn and creates two different .exp
files for intel and amd.
https://bugs.kde.org/show_bug.cgi?id=413330
Convert from dos to unix text files:
./none/tests/amd64-linux/cet_nops_fs.c
./none/tests/amd64-linux/cet_nops_gs.c
./none/tests/mips32/mips32_dspr2.c
./none/tests/mips32/mips32_dsp.c
This patch changes the option parsing framework to allow a set of
core or tool (currently only memcheck) options to be changed dynamically.
Here is a summary of the new functionality (extracted from NEWS):
* It is now possible to dynamically change the value of many command
line options while your program (or its children) are running under
Valgrind.
To have the list of dynamically changeable options, run
valgrind --help-dyn-options
You can change the options from the shell by using vgdb to launch
the monitor command "v.clo <clo option>...".
The same monitor command can be used from a gdb connected
to the valgrind gdbserver.
Your program can also change the dynamically changeable options using
the client request VALGRIND_CLO_CHANGE(option).
Here is a brief description of the code changes.
* the command line options parsing macros are now checking a 'parsing' mode
to decide if the given option must be handled or not.
(more about the parsing mode below).
* the 'main' command option parsing code has been split in a function
'process_option' that can be called now by:
- early_process_cmd_line_options
(looping over args, calling process_option in mode "Early")
- main_process_cmd_line_options
(looping over args, calling process_option in mode "Processing")
- the new function VG_(process_dynamic_option) called from
gdbserver or from VALGRIND_CLO_CHANGE (calling
process_option in mode "Dynamic" or "Help")
* So, now, during startup, process_option is called twice for each arg:
- once during Early phase
- once during normal Processing
Then process_option can then be called again during execution.
So, the parsing mode is defined so that the option parsing code
behaves differently (e.g. allows or not to handle the option)
depending on the mode.
// Command line option parsing happens in the following modes:
// cloE : Early processing, used by coregrind m_main.c to parse the
// command line options that must be handled early on.
// cloP : Processing, used by coregrind and tools during startup, when
// doing command line options Processing.
// clodD : Dynamic, used to dynamically change options after startup.
// A subset of the command line options can be changed dynamically
// after startup.
// cloH : Help, special mode to produce the list of dynamically changeable
// options for --help-dyn-options.
typedef
enum {
cloE = 1,
cloP = 2,
cloD = 4,
cloH = 8
} Clo_Mode;
The option parsing macros in pub_tool_options.h have now all a new variant
*_CLOM with the mode(s) in which the given option is accepted.
The old variant is kept and calls the new variant with mode cloP.
The function VG_(check_clom) in the macro compares the current mode
with the modes allowed for the option, and returns True if qq_arg
should be further processed.
For example:
// String argument, eg. --foo=yes or --foo=no
(VG_(check_clom) \
(qq_mode, qq_arg, qq_option, \
VG_STREQN(VG_(strlen)(qq_option)+1, qq_arg, qq_option"=")) && \
({const HChar* val = &(qq_arg)[ VG_(strlen)(qq_option)+1 ]; \
if VG_STREQ(val, "yes") (qq_var) = True; \
else if VG_STREQ(val, "no") (qq_var) = False; \
else VG_(fmsg_bad_option)(qq_arg, "Invalid boolean value '%s'" \
" (should be 'yes' or 'no')\n", val); \
True; }))
VG_BOOL_CLOM(cloP, qq_arg, qq_option, qq_var)
To make an option dynamically excutable, it is typically enough to replace
VG_BOOL_CLO(...)
by
VG_BOOL_CLOM(cloPD, ...)
For example:
- else if VG_BOOL_CLO(arg, "--show-possibly-lost", tmp_show) {
+ else if VG_BOOL_CLOM(cloPD, arg, "--show-possibly-lost", tmp_show) {
cloPD means the option value is set/changed during the main command
Processing (P) and Dynamically during execution (D).
Note that the 'body/further processing' of a command is only executed when
the option is recognised and the current parsing mode is ok for this option.
Modify the pth_self_kill_15_other test to make its behaviour deterministic
by introducing a pthread_join call. Do so by modifying the signal handler
for SIGTERM for the spawned thread which would issue the pthread_join call
prior to exiting.
This fixes KDE #410599.
Patch by Stefan Maksimovic.
The loop scenario:
The main thread sends a signal 15 to another thread, and then calls the exit syscall.
The exit syscall done by thread 1 marks all threads as needing
to die using exitreason VgSrc_ExitProcess.
The main thread then gets all other threads out of their blocking syscall
to let them die, and then "busy polls" for all other threads to disappear.
However, when the second thread is out of its syscall, it gets the signal 15,
which is a fatal signal. This second thread then changes the exit reason
of all threads to VgSrc_FatalSig, and itself starts to busy poll for all
other threads to disappear.
This then loops forever.
The fix for this consists in not handling the fatal signal in the
second thread when the process is already busy dying. Effectively,
the exit syscall should be processed "atomically": either the process
is running, or it is dead once the syscall is done.
Under valgrind, when threads are marked as being ' VgSrc_ExitProcess',
the guest process should be considered as dead. Valgrind has still to do
the cleanup, the endof run report, etc but otherwise should not let
any more user code to run. So, signal should not be handled anymore
once the 'exit syscall' has marked all threads as VgSrc_ExitProcess.
The hang scenario:
The main thread sends a signal 9 (KILL) to itself.
When running natively, this directly kills the process,
without giving any opportunity to run some user code.
Valgrind intercepts the kill syscall, and detects that this is
a fatal signal. The main thread was then dying, but was
not getting the other threads out of their syscall (to let them die).
The fix for this is to have the 'handling' of the signal 9 sent to a
thread of the process to directly make the process die, by getting
all threads out of syscall.
Note that the previous code was trying to have this action done by
the thread to which the signal 9 was sent. This was too tricky to
keep (causing other race conditions between the main thread sending
the signal 9 e.g. exiting and the other thread supposed to die).
As it is not particularly critical to have the signal 9 'handled'
by a specific thread, the thread that is sending the signal 9 is
the one doing the work to cleanup and terminate the process.
Reuse the existing infrastructure for add, sub and mul.
Add cc checks to all mul tests.
Write a new test for bic.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Add IBM z14 and IBM z14 ZR1 to the list of known machine models. Add an
expected output variant for z14 to the s390x-specific "ecag" test case.
In README.s390, refer to a current version of the z/Architecture
Principles of Operation that describes the instructions introduced with
IBM z14.
VEX patch fixed issues with generating subnormal results.
This patch adds a specific test case and updates the expected values for
the existing test case.
Update jm-vmx tests, add subnormal test case.
https://bugs.kde.org/show_bug.cgi?id=406256
Sync VEX/LICENSE.GPL with top-level COPYING file. We used 3 different
addresses for writing to the FSF to receive a copy of the GPL. Replace
all different variants with an URL <http://www.gnu.org/licenses/>.
The following files might still have some slightly different (L)GPL
copyright notice because they were derived from other programs:
- files under coregrind/m_demangle which come from libiberty:
cplus-dem.c, d-demangle.c, demangle.h, rust-demangle.c,
safe-ctype.c and safe-ctype.h
- coregrind/m_demangle/dyn-string.[hc] derived from GCC.
- coregrind/m_demangle/ansidecl.h derived from glibc.
- VEX files for FMA detived from glibc:
host_generic_maddf.h and host_generic_maddf.c
- files under coregrin/m_debuginfo derived from LZO:
lzoconf.h, lzodefs.h, minilzo-inl.c and minilzo.h
- files under coregrind/m_gdbserver detived from GDB:
gdb/signals.h, inferiors.c, regcache.c, regcache.h,
regdef.h, remote-utils.c, server.c, server.h, signals.c,
target.c, target.h and utils.c
Plus the following test files:
- none/tests/ppc32/testVMX.c derived from testVMX.
- ppc tests derived from QEMU: jm-insns.c, ppc64_helpers.h
and test_isa_3_0.c
- tests derived from bzip2 (with embedded GPL text in code):
hackedbz2.c, origin5-bz2.c, varinfo6.c
- tests detived from glibc: str_tester.c, pth_atfork1.c
- test detived from GCC libgomp: tc17_sembar.c
- performance tests derived from bzip2 or tinycc (with embedded GPL
text in code): bz2.c, test_input_for_tinycc.c and tinycc.c
On various systems none/tests/amd64-linux/map_32bits.vgtest fails with:
first mmap: Cannot allocate memory.
The problem is that the --aspace-minaddr is too tight. Newer glibc seem
to mmap some memory and so even our first mmap with MMAP_32BIT will fail.
The solution is to make a bit more memory < 2GB available.
If there is 16MB available the test always seems to succeed without
needing too many tries. The original 256K is too low.
https://bugs.kde.org/show_bug.cgi?id=406422
Valgrind ppc64 test_isa_3_0_other test will attempt to display
all of the bits of the XER as part of the test case results.
The tests have no existing logic to clear those bits, so this can
pick up straggling values that cascade into a testcase failure.
This adds some code to correct this in two directions;
- Print only the bits that are expected by the tests. This
is currently just the OV and OV32 bits.
- print all of the bits when run under higher verbosity levels.
Bugzilla 406198 - none/tests/ppc64/test_isa_3_0_other test sporadically
including CA bit in output
Patch submitted by Will Schmidt <will_schmidt@vnet.ibm.com>
Patch reviewed, committed by: Carl Love <cel@us.ibm.com>
This corrects a valgrind instruction emulation issue revealed by
a GCC change.
The xscvdpsp,xscvdpspn,xscvdpuxws instructions each convert
double precision values to single precision values, and write
the results into bits 0-32 of the 128 bit target register.
To get the value into the normal position for a scalar register
the result needed to be right-shifted 32 bits, so gcc always
did that.
It was determined that hardware also always did that, so the (redundant)
gcc shift was removed.
This exposed an issue because valgrind was only writing the result to
bits 0-31 of the target register.
This patch updates the emulation to write the result to both of the involved
32-bit fields.
VEX/priv/guest_ppc_toIR.c:
- rearrange ops in dis_vx_conv to update more portions of the target
register with copies of the result. xscvdpsp,xscvdpspn,xscvdpuxws
none/tests/ppc64/test_isa_2_06_part1.c
- update res32 checking to explicitly include fcfids and fcfidus in the
32-bit result grouping.
none/tests/ppc64/test_isa_2_07_part2.c
- correct NULL initializer for logic_tests definition
[*1] - GCC change referenced:
2017-09-26 Michael Meissner <meissner@linux.vnet.ibm.com>
* config/rs6000/rs6000.md (movsi_from_sf): Adjust code to
eliminate doing a 32-bit shift right or vector extract after
doing XSCVDPSPN.
patch submitted by: Will Schmidt <will_schmidt@vnet.ibm.com>
reviewed, committed by: Carl Love <cel@us.ibm.com>
Bug 398870 - Please add support for instruction vcvtps2ph
Bug 353370 - RDRAND amd64->IR: unhandled instruction bytes: 0x48 0xF 0xC7 0xF0
This commit implements:
* amd64 RDRAND instruction, on hosts that have it.
* amd64 VCVTPH2PS and VCVTPS2PH, on hosts that have it.
The presence/absence of these on the host is now reflected in the CPUID
results returned to the guest. So code that tests for these features in
CPUID and acts accordingly should "just work".
* New test cases, none/tests/amd64/rdrand and none/tests/amd64/f16c. These
are built if the host's assembler can handle them, in the usual way.
The libvexmultiarch_test failed on s390, since VEX was configured for MIPS64
with 32bit FPUs. Modify arch_hwcaps() to a realist case with 64bit FPUs.
This fixes KDE #402351.
addex uses OV as carry in and carry out. For all other instructions
OV is the signed overflow flag. And instructions like adde use CA
as carry.
Replace set_XER_OV_OV32 with set_XER_OV_OV32_ADDEX, which will
call calculate_XER_CA_64 and calculate_XER_CA_32, but with OV
as input, and sets OV and OV32.
Enable test_addex in none/tests/ppc64/test_isa_3_0.c and update
the expected output. test_addex would fail to match the expected
output before this patch.
The mfvscr and vor instructions in jm-insns.c had a "=vr" constraint.
This should have been an "=v" constraint. This resolved assembler
warnings and the testcase failing on ppc64le with gcc 8.2 and
binutils 2.30.
Add test cases for the z13 vector FP support. Bring s390-opcodes.csv
up-to-date, reflecting that the z13 vector instructions are now supported.
Also remove the non-support disclaimer for the vector facility from
README.s390.
The patch was contributed by Vadim Barkov, with some clean-up and minor
adjustments by Andreas Arnez.
Author: Nicholas Nethercote <nnethercote@mozilla.com>
Use inlined frames in Massif XTree output.
This makes Massif's output much easier to follow.
The commit also removes a -1 used on all Massif stack frame addresses.
There was a big comment questioning the presence of that -1, and with it
gone the addresses now match those produced by DHAT.
This adds test cases and some internal stuff to the z/Architecture vector
integer and string instruction support.
Contributed by Vadim Barkov <vbrkov@gmail.com>.
This implements various z/Architecture instructions that conditionally
yield a data exception ("trap"). The condition is either based on a
comparison being true ("compare and trap") or on a loaded value being
zero ("load and trap"). These instructions haven't been widely used in
the past, but may now be emitted by newer compilers. Note that the
resulting signal for a data exception is SIGFPE, not SIGTRAP. Thus this
patch also adds a new jump kind Ijk_SigFPE.
Adds test cases, that check both the 10h and 11h decodings. For some reason
the expected output diff is huge. I don't know why. It is the same as what
the hardware produces, though.
Apart from instructions with vector operands, Valgrind does not implement the
additional z/Architecture instructions introduced with z13.
These are:
- load and zero rightmost byte (LZRF, LZRG);
- load logical and zero rightmost byte (LLZRGF);
- load halfword high immediate on condition (LOCHHI);
- load halfword immediate on condition (LOCHI, LOCGHI);
- load high on condition (LOCFHR, LOCFH);
- store high on condition (STOCFH);
- perform pseudorandom number operation (PPNO), with the functions
PPNO-Query and PPNO-SHA-512-DRNG;
- load count to block boundary (LCBB).
Patches from Vadim Barkov (vbrkov@gmail.com), with coordination, testing
and format cleanups from Andreas Arnez (arnez@linux.ibm.com).
This test fails sporadically (eg, on Fedora 27 with gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5))
because the tested instruction uses RAX and RDX as input, but the test framework doesn't
set them :-/, so the outcome basically depends on whatever junk the compiler left in those
registers beforehand. As a result of this, all previous uses of RAX in the test have
been changed to use RSI instead. n-i-bz.
The ppc32 results were not updated when the xvnegsp instruction support
was added. Add the xvnegsp 32-bit results to
ppc/test_isa_2_06_part3.stdout.exp.
Signed-off-by: Carl Love <carll@us.ibm.com>
Missed the update to none/tests/ppc64/Makefile.am to remove the
expected output files test_isa_3_0_altivec.stdout.exp and
test_isa_3_0_other.stdout.exp.
