Fix compilation problem when __NR_preadv2 __NR_pwritev2 are undefined
check_preadv2_pwritev2.c: In function ‘main’:
check_preadv2_pwritev2.c:12:12: error: ‘__NR_preadv2’ undeclared (first use in this function)
syscall(__NR_preadv2, 0, NULL, 0, 0, 0);
^
check_preadv2_pwritev2.c:12:12: note: each undeclared identifier is reported only once for each function it appears in
check_preadv2_pwritev2.c:15:12: error: ‘__NR_pwritev2’ undeclared (first use in this function)
syscall(__NR_pwritev2, 0, NULL, 0, 0, 0);
Petar Jovanovic [Fri, 16 Aug 2019 15:57:50 +0000 (15:57 +0000)]
Use statx rather than other stat system calls
*STAT* system calls other than statx are becoming deprecated.
Coregrind should use statx as the first candidate in order to achieve
"stat" functionality.
There are also systems that do not even support older "stats".
Petar Jovanovic [Tue, 13 Aug 2019 14:51:37 +0000 (14:51 +0000)]
make pth_self_kill_15_other test deterministic
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.
Petar Jovanovic [Tue, 13 Aug 2019 12:19:30 +0000 (12:19 +0000)]
mips: pass 7th argument in syscalls
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.
Andreas Arnez [Tue, 6 Aug 2019 16:29:46 +0000 (18:29 +0200)]
s390x: Fix vector facility (vx) check in test suite
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.
Fix 409141 and 409367: valgrind hangs or loops when a process sends a signal to itself.
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=601cc11d054ae4b5e9b5babec3d8e4667a2cb9b5
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.
Replace 'error' by 'warning' when a signal cannot be translated to the gdb nr.
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).
Andreas Arnez [Tue, 14 May 2019 15:19:34 +0000 (17:19 +0200)]
s390x: Clean up s390-check-opcodes.pl
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.
Andreas Arnez [Tue, 2 Oct 2018 11:47:50 +0000 (13:47 +0200)]
s390x: Add models "z14" and "z14 ZR1"
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.
Mark Wielaard [Wed, 29 May 2019 22:29:58 +0000 (00:29 +0200)]
linux x86 and amd64 memory protection key syscalls.
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.
Mark Wielaard [Thu, 30 May 2019 01:40:56 +0000 (03:40 +0200)]
Fix -Wdiscarded-qualifiers warnings in launcher-linux.c
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.
Mark Wielaard [Mon, 27 May 2019 20:19:27 +0000 (22:19 +0200)]
Expose rdrand and f16c through cpuid also if the host only has avx.
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.
Carl Love [Tue, 28 May 2019 16:26:13 +0000 (11:26 -0500)]
PPC64, fix issues with dnormal values in the vector fp instructions.
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.
Andreas Arnez [Thu, 23 May 2019 15:17:43 +0000 (17:17 +0200)]
Bug 407764 - s390x: drd fails on z13 due to function wrapping issue
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.
Mark Wielaard [Mon, 27 May 2019 18:31:35 +0000 (20:31 +0200)]
ppc64: Arguments to iselInt128Expr_to_32x4 should be initialized.
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.
Mark Wielaard [Tue, 28 May 2019 15:20:31 +0000 (17:20 +0200)]
Fix coding nit in x86amd64g_calculate_FXTRACT.
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.
Mark Wielaard [Mon, 27 May 2019 18:50:02 +0000 (20:50 +0200)]
host_amd64_defs.c don't initialize opc and subopc_imm in emit_AMD64Instr.
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.
Mark Wielaard [Sat, 25 May 2019 22:32:28 +0000 (00:32 +0200)]
Cleanup GPL header address notices by using http://www.gnu.org/licenses/
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
Mark Wielaard [Sat, 25 May 2019 14:38:42 +0000 (16:38 +0200)]
Fix DIP instruction name typos in guest_amd64_toIR.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.
Mark Wielaard [Sat, 25 May 2019 14:31:02 +0000 (16:31 +0200)]
Fix memory leak in launcher-linux.c
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.
Mark Wielaard [Sat, 25 May 2019 14:25:19 +0000 (16:25 +0200)]
vgdb: Fix read check in report_pid.
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.
Mark Wielaard [Fri, 24 May 2019 19:51:31 +0000 (21:51 +0200)]
Fix memcheck/tests/linux/sys-copy_file_range open call (mode).
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
Mark Wielaard [Mon, 20 May 2019 11:08:41 +0000 (13:08 +0200)]
Make memcheck/tests/x86-linux/scalar test work under root.
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.
Mark Wielaard [Sun, 19 May 2019 22:09:59 +0000 (00:09 +0200)]
Make memcheck/tests/arm64-linux/scalar test work under root.
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.
Mark Wielaard [Sat, 18 May 2019 12:55:50 +0000 (14:55 +0200)]
aarch64 (arm64) isn't a supported architecture for exp-sgcheck.
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.
Mark Wielaard [Wed, 15 May 2019 19:30:00 +0000 (21:30 +0200)]
Explicitly make testcase variable for sys-copy_file_range undefined.
On some systems an extra warning could occur when a variable in
the memcheck/tests/linux/sys-copy_file_range testcase was undefined,
but (accidentially) pointed to known bad memory. Fix by defining the
variable as 0, but then marking it explicitly undefined using memcheck
VALGRIND_MAKE_MEM_UNDEFINED.
Followup for https://bugs.kde.org/show_bug.cgi?id=407218
Mark Wielaard [Tue, 7 May 2019 19:20:04 +0000 (21:20 +0200)]
Intercept stpcpy also in ld.so for arm64
On other arches stpcpy () is intercepted for both libc.so and ld.so.
But not on arm64, where it is only intercepted for libc.so.
This can cause memcheck warnings about the use of stpcpy () in ld.so
when called through dlopen () because ld.so contains its own copy of
that functions.
Fix by introducing VG_Z_LD_LINUX_AARCH64_SO_1 (the encoded name of
ld.so on arm64) and using that in vg_replace_strmem.c to intercept
stpcpy.
Make the list of horrible filter_gdb sed expressions somewhat less horrible
The sed expressions and the comments of these expression were at 2 different
places, making this already horrible list of expressions even more
horrible to understand/maintain.
So, restructure to allow the comments for an expression be close
to the expression.
Mark Wielaard [Thu, 11 Apr 2019 16:06:34 +0000 (18:06 +0200)]
none/tests/amd64-linux/map_32bits.vgtest fails too easily
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.
Mark Wielaard [Thu, 11 Apr 2019 16:01:24 +0000 (18:01 +0200)]
filter_libc: remove the line holding the futex syscall error entirely
The current filter might leave empty lines behind.
This is caused by the fact that glibc used to not include a newline
in the message. But since glibc 2.29 it does.
https://bugs.kde.org/show_bug.cgi?id=405205 Reported-by: Stefan Maksimovic <stefan.maksimovic@rt-rk.com>
gdbserver_tests: adjust filtering for the new gdb output
mcsigpass and mcsignopass tests fails due to the slightly different
gdb output. Filter the tests output to make it the same for different
gdb version. Change mcsigpass and mcsignopass .exp to fit filtered
.out.
More generic regexp by Stefan Maksimovic <stefan.maksimovic@rt-rk.com>.
Mark Wielaard [Tue, 9 Apr 2019 23:22:37 +0000 (01:22 +0200)]
dhat is broken on x86 (32bit)
dhat will crash on x86 (32bit) because it doesn't handle Vg_CoreClientReq
in its track_post_mem_write.
dh_handle_noninsn_write will be called with Vg_CoreClientReq during
shutdown when trying to setup an argument for the freeres_wrapper().
On other architectures this will be done through a register, but on
x86 we setup the argument on the stack. See final_tidyup () in
coregrind/m_main.c.
Just handle it like a syscall memory argument write.
Mark Wielaard [Tue, 9 Apr 2019 14:09:50 +0000 (16:09 +0200)]
More memcheck/tests/libstdc++.supp suppressions
memcheck/tests/leak_cpp_interior might fail because depending on compiler
and arch used the suppression file used doesn't catch some allocations
through the DT_INIT_ARRAY functions.
That memory doesn't actually leak, it gets freed by the
__gnu_cxx::__freeres hook. But since this testcase shows leaks while
running, not after the program ends, it needs to suppress these allocations.
Mark Wielaard [Sun, 7 Apr 2019 20:27:52 +0000 (22:27 +0200)]
Add arm64 do_syscall_WRK implementation to memcheck/tests/leak-segv-jmp.
On arm64-linux memcheck/tests/leak-segv-jmp would fail because there
was no do_syscall_WRK implementation for that architecture. Implement
and adjust line numbers in .exp file to make it PASS.
Carl Love [Fri, 5 Apr 2019 20:04:23 +0000 (15:04 -0500)]
PPC64, fix test_isa_3_0_other.c test
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>
Bug 404843 - s390x: backtrace sometimes ends prematurely.
On s390x-linux, adds CFI based unwinding for %f0..%f7, since these are sometimes
used by gcc >= 8.0 to spill integer register values in leaf functions. Hence the
lack of unwinding them was causing unwind failures on this platform.
Carl Love [Thu, 4 Apr 2019 17:31:05 +0000 (12:31 -0500)]
PPC64, patch to test case issues reported in bugzilla 401827 and 401828.
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>
projects / thirdparty / valgrind.git / log
