Hook up sys_tee for mips32 and mips64 correctly.
For mips64, it is just a simplification to use generic linux implementation.
This fixes tee01 test in the LTP test suite for mips32.
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.
Hook up sync_file_range for mips32.
Along with the change for passing 7th argument in syscalls, this will fix
sync_file_range01 failure within LTP test suite.
Patch by Nikola Milutinovic.
Only arg1 to arg6 have been passed down to kernel for syscalls.
This patch ensures that arg7 is also passed down for syscalls.
In addition to this, ensure that we have 16-byte aligned stack during
mips64 syscall.
Along with the change for sync_file_range, this will fix sync_file_range01
failure within LTP test suite.
Patch by Nikola Milutinovic.
When checking the prereqisuites of running a vector test case, it is not
sufficient to check for the appropriate CPU facility bit. It must also be
verified that the kernel and hypervisor(s) have actually enabled the
vector facility. There are various ways of checking this. E.g., we could
try executing a vector instruction and handle any signals. Or we can
check the HWCAP for the appropriate bit. This patch does the latter.
Use the correct generic linux sys wrapper.
Follow-up for
commit b0861063a8
Author: Alexandra Hajkova <ahajkova@redhat.com>
Date: Tue Jun 4 13:47:14 2019 +0200
Add support for preadv2 and pwritev2 syscalls
This should fix
memcheck/tests/linux/sys-preadv2_pwritev2 (stderr)
memcheck/tests/linux/sys-preadv_pwritev (stderr)
on mips32/mips64.
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.
Support for amd64, x86 - 64 and 32 bit, arm64, ppc64, ppc64le,
s390x, mips64. This should work identically on all
arches, tested on x86 32bit and 64bit one, but enabled on all.
Refactor the code to be reusable between old/new syscalls. Resolve TODO
items in the code. Add the testcase for the preadv2/pwritev2 and also
add the (similar) testcase for the older preadv/pwritev syscalls.
Trying to test handling an uninitialized flag argument for the v2 syscalls
does not work because the flag always comes out as defined zero.
Turns out glibc does this deliberately on 64bit architectures because
the kernel does actually have a low_offset and high_offset argument, but
ignores the high_offset/assumes it is zero.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=601cc11d054ae4b5e9b5babec3d8e4667a2cb9b5https://bugs.kde.org/408414
Introduce new header files for the system call numbers that are shared
across all Linux architectures and also for the system call numbers that
are shared across all 32-bit architectures.
As 'error' is supposed to be called only to go back at gdbserver toplevel,
and such signal translations can be called during tracing, when
gdbserver is not active : 'error' then tries to longjmp using a
not initialised longjmp buffer.
(reproduced by activating the trace with the test case attached in
bug 409141 - Valgrind hangs when SIGKILLed).
Update expected file for 32-bit platforms.
This is a follow up to:
commit bc758374a2
Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Date: Sat May 18 12:10:40 2019 +0200
Add a test for the new gdbserver adddress[length] syntax.
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>
(from bug 404406 comment 0):
Valgrind on s390x currently lacks support for the miscellaneous
instruction extensions facility 2.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Fix false positives when invoking s390-check-opcodes.pl. Also clean up
some code formatting issues in that script. Add the instructions TPEI and
IRBM to guest_s390_toIR.c and s390-opcodes.csv, so they are not longer
warned about.
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.
This implements minimal support for the pkey_alloc, pkey_free and
pkey_mprotect syscalls. pkey_alloc will simply indicate that pkeys
are not supported. pkey_free always fails. pkey_mprotect works just
like mprotect if the special pkey -1 is provided.
https://bugs.kde.org/show_bug.cgi?id=408091
commit f15bee "Fix memory leak in launcher-linux.c" introduced some
warnings about passing const pointers to free.
warning: passing argument 1 of ‘free’ discards ‘const’ qualifier from
pointer target type [-Wdiscarded-qualifiers]
This was because that code was a little too "smart". The compiler cannot
know that we really only call free () when the pointer was dynamically
allocated. Simplify the code a little to just always allocate a new
string in find_client and always free that string in select_platform.
The amd64 CPUID dirtyhelpers are mostly static since they emulate some
existing CPU "family". The avx2 ("i7-4910MQ") CPUID variant however
can "dynamicly" enable rdrand and/or f16c if the host supports them.
Do the same for the avx_and_cx16 ("i5-2300") CPUID variant.
https://bugs.kde.org/show_bug.cgi?id=408009
Add Iop_Exp2_32Fx4 to VEX/pub/libvex_ir.h to support the 2^x instruction.
Enable the existing test support for the two instructions in
none/tests/ppc64/subnormal_test.c and none/tests/ppc64/jm-insns.c.
https://bugs.kde.org/show_bug.cgi?id=407340
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
The result of the floating point instructions vmaddfp, vnmsubfp,
vaddfp, vsubfp, vmaxfp, vminfp, vrefp, vrsqrtefp, vcmpeqfp, vcmpeqfp,
vcmpgefp, vcmpgtfp are controlled by the setting of the NJ bit in
the VSCR register. If VSCR[NJ] = 0; then denormalized values are
handled as specified by Java and the IEEE standard. If the bit is
a 1, then the denormalized element in the vector is replaced with
a zero.
Valgrind was not properly handling the denormalized case for these
instructions. This patch fixes the issue.
https://bugs.kde.org/show_bug.cgi?id=406256
The s390x-specific inline assembly macros for function wrapping in
include/valgrind.h have a few issues.
When the compiler uses vector registers, such as with "-march=z13", all
vector registers must be declared as clobbered by the callee. Because
this is missing, many drd test failures are seen with "-march=z13".
Also, the inline assemblies write the return value into the target
register before restoring r11. If r11 is used as the target register,
this means that the restore operation corrupts the result. This bug
causes failures with memcheck's "wrap6" test case.
These bugs are fixed. The clobber list is extended by the vector
registers (if appropriate), and the target register is now written at the
end, after restoring r11.
Make sure to initialize the arguments to iselInt128Expr_to_32x4.
iselInt128Expr_to_32x4 will check that iselInt128Expr_to_32x4_wrk
has assigned the correct type of values to the arguments. But if
the arguments were never initialized it might not be able to when
iselInt128Expr_to_32x4_wrk was unable to assign a value.
Reviewed-by: Carl Love <cel@us.ibm.com>
The current code "return getExp ? posInf : posInf;" looks like a typo.
But when the argument is positive infinity then both the significand
and the exponent are positive infinity (there is a fxtract testcase that
checks that). So no need to check getExp. Just always return posInf
if arg == posInf, but add a comment explaining why.
In the case of Ain_SseShiftN we first assign zero to opc and subopc_imm
before handling the various subops. But since we will (and must) always
assign a valid value to opc and subopc_imm we might get a compiler warning
about the values never being read before storing a different value.
So explicitly don't assign a value. Then the compiler will warn if we
would ever forget to assign it a value value later on before using it.
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
DIP would print the wrong instruction name for blendps, vroundpd and
vpinsrq. Which would be confusing when trying to debug the disassembly.
These were probably typos or copy/paste errors since they would print
very similar instruction names.
When the clientname argument is not a full absolute path we reconstruct
the full path using $PATH. This reconstructed full path would be leaked.
This is small and insignificant. But valgrind should give a good example.
So free the path again when we are done and allocated the memory.
Also don't print the path twice in the debug output if we didn't need to
construct a new different path for it.
When read fails it will return -1. In which case we might assign
cmdline[sz] = 0 and print a garbage cmdline. Fix the test to check
the return value is > 0.
sys-copy_file_range.c calls open with O_CREAT flag and so must provide
a mode argument. valgrind memcheck actually caught this ommission on
some arches (fedora rawhide i686 specifically).
This is a small additional fixup for
https://bugs.kde.org/show_bug.cgi?id=407218
Running the testsuite as root isn't really recommended.
But lets not make tests fail unnecessarily when running as root.
Similar to the arm64-linux/scalar fixes. Plus 32bit variants that
don't exist on arm64.
Pass really invalid arguments to setuid[32], setgid[32], acct, fchown[32].
Make setresgid[32], setresuid[32], setregid[32], setreuid[32] always succeed.
Running the testsuite as root isn't really recommended.
But lets not make tests fail unnecessarily when running as root.
Pass really invalid arguments to setuid, setgid, acct and fchown.
Make setresgid, setresuid, setregid and setreuid always succeed.
exp-sgcheck/pc_main.c contains:
#if defined(VGA_arm) || defined(VGA_arm64)
VG_(printf)("SGCheck doesn't work on ARM yet, sorry.\n");
VG_(exit)(1);
#endif
But exp-sgcheck/tests/is_arch_supported checked against uname -m
which returns aarch64 (not arm64). Fix the test check so the
exp-sgcheck tests are skipped instead of producing failures.
The syntax address[length] can be used in all the gdbserer monitor
commands that need an address and optional length argument.
This commit also fixes an error message, and removes trailing whitespaces
in m_gdbserver.c
