Patches from Bug #400872 (Add nanoMIPS support to Valgrind) have been
merged.
Update README.mips with a correct configure line applicable for the latest
nanomips toolchain package in public.
Necessary changes to support nanoMIPS on Linux.
Part 4/4 - Other changes (mainly include/*)
Patch by Aleksandar Rikalo, Dimitrije Nikolic, Tamara Vlahovic,
Nikola Milutinovic and Aleksandra Karadzic.
Related KDE issue: #400872.
Specific use case bug found in SysRes VG_(do_sys_sigprocmask).
Fix for case when ,,set,, parameter is NULL.
In this case ,,how,, parameter should be ignored because we are
only requesting from kernel to put current signal mask into ,,oldset,,.
But instead we determine the action based on ,,how,, parameter and
therefore make the system call fail when it should pass.
Taken from linux man pages (sigprocmask).
The same is specified for POSIX.
https://bugs.kde.org/show_bug.cgi?id=414565
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
If configure is invoked with e.g.
CFLAGS='--sysroot=/workspace/linux-mips64/sysroot -mabi=64'
flags FLAG_M32 and FLAG_M64 are not set, because the grep search in
configure.ac mismatches the mips keyword in the path.
Update the grep patterns to anchor on non-word boundaries.
This fixes KDE #412344.
Patch by Chris Packham.
- The command option --collect-systime has been enhanced to specify
the unit used to record the elapsed time spent during system calls.
The command option now accepts the values no|yes|msec|usec|nsec,
where yes is a synonym of msec. When giving the value nsec, the
system cpu time of system calls is also recorded.
Note that the nsec option is not supported on Darwin.
As it turned out, the size of vki_siginfo_t is incorrect on these 64-bit
architectures:
(gdb) p sizeof(vki_siginfo_t)
$1 = 136
(gdb) ptype struct vki_siginfo
type = struct vki_siginfo {
int si_signo;
int si_errno;
int si_code;
union {
int _pad[29];
struct {...} _kill;
struct {...} _timer;
struct {...} _rt;
struct {...} _sigchld;
struct {...} _sigfault;
struct {...} _sigpoll;
} _sifields;
}
It looks like that for this architecture, __VKI_ARCH_SI_PREAMBLE_SIZE
hasn't been defined properly, which resulted in incorrect
VKI_SI_PAD_SIZE calculation (29 instead of 28).
<6a9e4> DW_AT_name : (indirect string, offset: 0xcf59): _sifields
<6a9ef> DW_AT_data_member_location: 16
This issue has been discovered with strace's "make check-valgrind-memcheck",
which produced false out-of-bounds writes on ptrace(PTRACE_GETSIGINFO) calls:
SYSCALL[24264,1](101) sys_ptrace ( 16898, 24283, 0x0, 0x606bd40 )
==24264== Syscall param ptrace(getsiginfo) points to unaddressable byte(s)
==24264== at 0x575C06E: ptrace (ptrace.c:45)
==24264== by 0x443244: next_event (strace.c:2431)
==24264== by 0x443D30: main (strace.c:2845)
==24264== Address 0x606bdc0 is 0 bytes after a block of size 144 alloc'd
(Note that the address passed is 0x606bd40 and the address reported is
0x606bdc0).
After the patch, no such errors observed.
* include/vki/vki-amd64-linux.h [__x86_64__ && __ILP32__]
(__vki_kernel_si_clock_t): New typedef.
[__x86_64__ && __ILP32__] (__VKI_ARCH_SI_CLOCK_T,
__VKI_ARCH_SI_ATTRIBUTES): New macros.
[__x86_64__ && !__ILP32__] (__VKI_ARCH_SI_PREAMBLE_SIZE): New macro,
define to 4 ints.
* include/vki/vki-arm64-linux.h (__VKI_ARCH_SI_PREAMBLE_SIZE): Likewise.
* include/vki/vki-ppc64-linux.h [__powerpc64__] (__VKI_ARCH_SI_PREAMBLE_SIZE):
Likewise.
* include/vki/vki-linux.h [!__VKI_ARCH_SI_CLOCK_T]
(__VKI_ARCH_SI_CLOCK_T): New macro, define to vki_clock_t.
[!__VKI_ARCH_SI_ATTRIBUTES] (__VKI_ARCH_SI_ATTRIBUTES): New macro,
define to nil.
(struct vki_siginfo): Use __VKI_ARCH_SI_CLOCK_T type for _utime and
_stime fields. Add __VKI_ARCH_SI_ATTRIBUTES.
Resolves: https://bugs.kde.org/show_bug.cgi?id=405201
Reported-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Eugene Syromyatnikov <evgsyr@gmail.com>
Note that the fix for 411134 contains a bunch of white space only changes.
To see the diff without the white spaces, do:
git diff -w 3a803036^..3a803036
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.
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
(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>
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
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
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.
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
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.
https://bugs.kde.org/show_bug.cgi?id=407307
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
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>.
https://bugs.kde.org/show_bug.cgi?id=406355
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.
https://bugs.kde.org/show_bug.cgi?id=406354
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.
https://bugs.kde.org/show_bug.cgi?id=406360
cachegrind/callgrind fails ann[12] tests because of missing a.c
These testcases fail because the dist tar is missing the a.c
(auto-annotated) source file. Fix by adding it to EXTRA_DIST.
https://bugs.kde.org/show_bug.cgi?id=406352
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>
