Rhys Kidd [Mon, 2 Oct 2017 00:57:04 +0000 (20:57 -0400)]
gitignore: Fix up false directory-level .gitignore settings
So we never intended to ignore all changes from the top-level down in /include
or /cachegrind. Instead allow the filetype-specific .gitignore patterns match
to the contents of these two folders.
Also, don't ignore changes to include/valgrind.h as it exists in the repository
and should be tracked for any changes developers might make.
Changes tested by running a git clean force and then full rebuild. No stray
build artifacts were being tracked erroneously by git after these changes.
Ivo Raisr [Tue, 26 Sep 2017 07:33:27 +0000 (09:33 +0200)]
Reorder allocatable registers for s390x so that the callee saved are listed first.
Helper calls always trash all caller saved registers. By listing the callee saved
first then VEX register allocator (both v2 and v3) is more likely to pick them
and does not need to spill that much before helper calls.
Follow up to 'On ppc, add generic_start_main.isra.0 as a below main function'
massif/tests/mmapunmap on ppc now indicates a below main function.
Note: this ppc53 specific file is needed because the valgrind stack unwinder
does not properly unwind in main.
At the mmap syscall, gdb backtrace gives:
Breakpoint 3, 0x00000000041dbae0 in .__GI_mmap () from /lib64/libc.so.6
(gdb) bt
while the valgrind stack trace gives:
Thread 1: status = VgTs_Runnable (lwpid 64207)
==64207== at 0x41DBAE0: mmap (in /usr/lib64/libc-2.17.so)
==64207== by 0x10000833: f (mmapunmap.c:9)
==64207== by 0x40E6BEB: (below main) (in /usr/lib64/libc-2.17.so)
client stack range: [0x1FFEFF0000 0x1FFF00FFFF] client SP: 0x1FFF00ECE0
valgrind stack top usage: 15632 of 1048576
On ppc, add generic_start_main.isra.0 as a below main function
We can have stacktraces such as:
==41840== by 0x10000927: a1 (deep.c:27)
==41840== by 0x1000096F: main (deep.c:35)
==41840== by 0x4126BEB: generic_start_main.isra.0 (in /usr/lib64/libc-2.17.so)
==41840== by 0x4126E13: __libc_start_main (in /usr/lib64/libc-2.17.so)
So, add generic_start_main.isra.0 as a below main function.
This fixes the test massif/tests/deep-D
massif: match --ignore-fn with the first IP that has a fnname
Currently, --ignore-fn is only matched with the top IP entries that
have a fnname. With this change, we first search for the first IP that
has a fnname.
This e.g. allows to ignore the allocation for a stacktrace such as:
0x1 0x2 0x3 fn_to_ignore otherfn
This is then used in massif c++ tests new-cpp and overloaded-new to ignore
the c++ libstdc++ allocation similar to:
==10754== 72,704 bytes in 1 blocks are still reachable in loss record 10 of 10
==10754== at 0x4C2BBCD: malloc (vg_replace_malloc.c:299)
==10754== by 0x4EC39BF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22)
==10754== by 0x400F8A9: call_init.part.0 (dl-init.c:72)
==10754== by 0x400F9BA: call_init (dl-init.c:30)
==10754== by 0x400F9BA: _dl_init (dl-init.c:120)
==10754== by 0x4000C59: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
Follow up to 345307 - Warning about "still reachable" memory when using libstdc++ from gcc 5
The bug itself was solved in 3.12 by the addition of __gnu_cxx::__freeres
in the libstdc++ and have valgrind calling it before exit.
However, depending on the version of the libstdc++, the test leak_cpp_interior
was giving different results.
This commit adds some filtering specific to the test, so as to not depend
anymore of the absolute number of bytes leaked, and adds a suppression entry to
ignore the memory allocated by libstdc++.
This allows to have only 2 .exp files, instead of 4 (or worse, if
we would have to handle yet other .exp files depending on the libstdc++
version).
gdbserver_tests/hgtls is failing on a number of platforms
as it looks like static tls handling is now needed.
So, omplement static tls for a few more platforms.
The formulas that are platform dependent are somewhat wild guesses
obtained with trial and errors.
Note that arm/arm64/ppc32 are not (yet) done
The below commit introduced a regression on ppc32
ommit 00d4667295a821fef9eb198abcb0c942dffb6045
Author: Ivo Raisr <ivosh@ivosh.net>
Date: Wed Sep 6 08:10:36 2017 +0200
Reorder allocatable registers for AMD64, X86, and PPC so that the callee saved are listed first.
Helper calls always trash all caller saved registers. By listing the callee saved
first then VEX register allocator (both v2 and v3) is more likely to pick them
and does not need to spill that much before helper calls.
Petar Jovanovic [Fri, 15 Sep 2017 16:29:29 +0000 (18:29 +0200)]
mips: finetune none/tests/(mips32|64)/test_math test
Compiler may optimize out call to cbrt. Change test to prevent that.
Otherwise, the test does not exercise a desired codepath for cbrt, and it
prints precalculated value.
Ivo Raisr [Wed, 6 Sep 2017 06:10:36 +0000 (08:10 +0200)]
Reorder allocatable registers for AMD64, X86, and PPC so that the callee saved are listed first.
Helper calls always trash all caller saved registers. By listing the callee saved
first then VEX register allocator (both v2 and v3) is more likely to pick them
and does not need to spill that much before helper calls.
The code handling array bounds is not ready to accept a reference
to something else (not very clear what this reference could be) :
the code only expects directly the value of a bound.
So, it was using the reference (i.e. an offset somewehere in the debug
info) as the value of the bound.
This then gave huge bounds for some arrays, causing an overlap
in the stack variable handling code in exp-sgcheck.
Such references seems to be used sometimes for arrays with variable
size stack allocated.
Fix (or rather bypass) the problem by not considering that we have
a usable array bound when a reference is given.
Ivo Raisr [Sat, 9 Sep 2017 20:08:21 +0000 (22:08 +0200)]
Reduce number of spill instructions generated by VEX register allocator v3.
Keeps track whether the bound real register has been reloaded from a virtual
register recently and if this real reg is still equal to that spill slot.
Avoids unnecessary spilling that vreg later, when this rreg needs
to be reserved, usually as a caller save register for a helper call.
Julian Seward [Thu, 31 Aug 2017 09:11:25 +0000 (11:11 +0200)]
Improve the implementation of expensiveCmpEQorNE.
.. so that the code it creates runs in approximately half the time it did
before. This is in support of making the cost of expensive (exactly)
integer EQ/NE as low as possible, since the day will soon come when we'll
need to enable this by default.
Julian Seward [Wed, 30 Aug 2017 17:43:59 +0000 (19:43 +0200)]
amd64 back end: handle CmpNEZ64(And64(x,y)) better; ditto the 32 bit case.
Handle CmpNEZ64(And64(x,y)) by branching on flags, similarly to
CmpNEZ64(Or64(x,y)). Ditto the 32 bit equivalents. Also, remove expensive
DEFINE_PATTERN/DECLARE_PATTERN uses there and hardwire the matching logic.
n-i-bz. This is in support of reducing the cost of expensiveCmpEQorNE
in memcheck.
Ivo Raisr [Fri, 25 Aug 2017 22:19:05 +0000 (00:19 +0200)]
VEX register allocator version 3.
Implements a new version of VEX register allocator which
keeps the main state per virtual registers, as opposed
to real registers in v2. This results in a simpler and
cleaner design and much simpler implementation.
It has been observed that the new allocator executes 20-30%
faster than the previous one but could produce slightly worse
spilling decisions. Overall performance improvement when running
the Valgrind performance regression test suite has been observed
in terms of a few percent.
The new register allocator (v3) is now the default one.
The old register allocator (v2) is still kept around and can be
activated with command line option '--vex-regalloc-version=2'.
Petar Jovanovic [Tue, 22 Aug 2017 13:53:15 +0000 (15:53 +0200)]
mips: reimplement handling of div, divu and ddivu
Previous implementation misused some opcodes, and a side effect was
dead code emission.
To reimplement handling of these instructions, three new IoPs have been
introduced:
Iop_DivModU64to64, // :: I64,I64 -> I128
// of which lo half is div and hi half is mod
Iop_DivModS32to32, // :: I32,I32 -> I64
// of which lo half is div and hi half is mod
Iop_DivModU32to32, // :: I32,I32 -> I64
// of which lo half is div and hi half is mod
Ivo Raisr [Fri, 18 Aug 2017 14:53:57 +0000 (16:53 +0200)]
Recognize signal 151 (SIGLIBRT) sent by gdb.
It has been observed that gdb on Solaris sends this signal to
child processes. Unfortunately array "pass_signals" was too small
to accomodate this signal and subsequently VG_(clo_vex_control).iropt_verbosity
was overwritten.
This has been fixed now.
Petar Jovanovic [Thu, 17 Aug 2017 18:08:17 +0000 (20:08 +0200)]
mips32: finetune vfp test to avoid compiler warnings
This patch removes two compiler warnings from the test:
vfp.c: In function 'handler':
vfp.c:260:4: warning: implicit declaration of function 'exit'
[-Wimplicit-function-declaration]
exit(0);
^
vfp.c:260:4: warning: incompatible implicit declaration of built-in
function 'exit'
vfp.c: At top level:
vfp.c:258:13: warning: 'handler' defined but not used [-Wunused-function]
static void handler(int sig)
^
Ensure host stack trace has better chance to work when valgrind is exiting
When investigating bug 383275, the host stacktrace was containing
only one IP. This is because the tid corresponding to the lwpid
is dead, and so no valid thread state was returned.
This then gave a rubbish stacktop of 0, which means unwinding
stops at first frame.
So, try harder to find a valid thread state when reporting the
host stacktrace.
When a massif xtree snapshot is taken when no allocation was done,
the xtree contains no exe context.
The data structure ips_order_xecu is then szied to 0 using VG_(hintSizeXA).
m_xarray.c then allocates an empty array, while later on, a zero size
is expected to correspond to no allocated array.
Fix the problem in m_xarray.c, by not doing any allocation if the
size hint is 0.
Ivo Raisr [Fri, 28 Jul 2017 20:49:20 +0000 (20:49 +0000)]
Check whether it is ok to use compiler flag '-pie'.
Some compilers actually do not support -pie and report its usage
as an error. We need to check if it is safe to use it first.
n-i-bz
valgrind core side for Add inner requests in VEX (cfr revision 3399)
When running Valgrind under Valgrind, the VEX memory allocation
(temporary or permanent) was not checked, as there was no
inner request.
This patch changes VEX to mark the temporary and permanent
allocations with redzone, and memory is marked unaddressable
when the VEX temporary pool is cleared.
The changes are:
* add a file libvex_inner.h which mostly takes over what
was in pub_core_inner.h (which now just includes libvex_inner.h)
* modify main_util.h and main_util.c to mark the temporary
and permanent pool with memcheck pool requests to indicate
when a block is allocated or freed.
* Impact is (should be) none, unless Valgrind is configured
as an inner.
* Outer memcheck/inner regression tests run on gcc20 (amd64).
Nothing (more worrying than the 3.13 self hosting) detected
When running Valgrind under Valgrind, the VEX memory allocation
(temporary or permanent) was not checked, as there was no
inner request.
This patch changes VEX to mark the temporary and permanent
allocations with redzone, and memory is marked unaddressable
when the VEX temporary pool is cleared.
The changes are:
* add a file libvex_inner.h which mostly takes over what
was in pub_core_inner.h (which now just includes libvex_inner.h)
* modify main_util.h and main_util.c to mark the temporary
and permanent pool with memcheck pool requests to indicate
when a block is allocated or freed.
* Impact is (should be) none, unless Valgrind is configured
as an inner.
* Outer memcheck/inner regression tests run on gcc20 (amd64).
Nothing (more worrying than the 3.13 self hosting) detected
ld.so: Reject overly long LD_PRELOAD path elements
arm32 doesn't have an ld.so hardwire for index/strchr like other
architectures and so will always complain during early startup:
==9495== Conditional jump or move depends on uninitialised value(s)
==9495== at 0x401CF84: index (in /usr/lib/ld-2.25.so)
==9495==
==9495== Conditional jump or move depends on uninitialised value(s)
==9495== at 0x401CF88: index (in /usr/lib/ld-2.25.so)
index/strchr is doing a word load from a partially-written
stack-allocated buffer, therefore accessing uninitialized data.
This is normal for an optimized string function. The uninitialized
data does not affect the function result.
This can be suppressed by adding a index hardwire for ld.so on arm32
like on other arches. There even was already some commented out code
to do that. Enable that code.
After fork, vgdb activity is polled according to the nr of bbs done :
once the nr of bbs done reaches the next vgdb poll, a check for vgdb
activity is done.
This might lead to the activation of gdbserver after fork.
Such poll is however not expected, unless the children is
to be trace.
This spurious poll in the forked child can cause failures
depending on the nr of bbs done before the fork, and the
nr of bbs done between the fork and the exec.
=> disable vgdb poll in the child in the cleanup after fork
in the child, unless the children have to be traced.
At the beginning of a Valgrind gdbserver test,
2 messages are produced when launching the command
target remote | vgdb
A message output by vgdb:
relaying data between gdb and process <pid>
(this message is read by GDB from the vgdb pipe, and re-output
on stderr)
and a message produced by GDB:
Remote debugging using | ./vgdb
GDB 8.0 changes the order in which the above messages are output.
This causes 2 tests to fail, as the 'relaying' line appears
then in a part of the output deleted by a filter script.
To avoid this, change the filter scripts to always remove
this 'relaying line', which is not particularly interesting to check.
All the .exp files containining such a 'relaying' line are updated
accordingly.
This has been tested with various gdb versions (7.5, 7.7, 7.12, 8.0)
on amd64 and/or ppc64.
Thanks to Mark Wielaard, which helped to investigate this problem
by bisecting the GDB patches in GDB 8.0 causing this change of
behaviour.
Mark Wielaard [Tue, 20 Jun 2017 17:55:13 +0000 (17:55 +0000)]
Bug 381274 powerpc too chatty even with --sigill-diagnostics=no.
Even with valgrind --sigill-diagnostics=no (or -q) guest_ppc_toIR.c
will report various cases why it didn't handle an instruction. e.g.
disInstr(ppc): found the Power 8 instruction 0x10000508 that can't be
handled by Valgrind on this host. This instruction requires a host
that supports Power 8 instructions.
After which valgrind will generate a SIGILL. But in case the user uses
-q or --sigill-diagnostics=no they aren't interested in that diagnostics.
For example openssl will try some power 8 instructions while initializing
and catch the SIGILL if not supported without issue.
Guard those cases with if (sigill_diag) like the generic decode_failure.
Mark Wielaard [Sat, 17 Jun 2017 13:49:22 +0000 (13:49 +0000)]
epoll_pwait can have a NULL sigmask.
According to the epoll_pwait(2) man page:
The sigmask argument may be specified as NULL, in which case
epoll_pwait() is equivalent to epoll_wait().
But doing that under valgrind gives:
==13887== Syscall param epoll_pwait(sigmask) points to unaddressable byte(s)
==13887== at 0x4F2B940: epoll_pwait (epoll_pwait.c:43)
==13887== by 0x400ADE: main (syscalls-2007.c:89)
==13887== Address 0x0 is not stack'd, malloc'd or (recently) free'd
This is because the sys_epoll_pwait wrapper has:
if (ARG4)
PRE_MEM_READ( "epoll_pwait(sigmask)", ARG5, sizeof(vki_sigset_t) );
Which looks like a typo (ARG4 is timeout and ARG5 is sigmask).
This shows up with newer glibc which translates an epoll_wait call into
an epoll_pwait call with NULL sigmask.
Mark Wielaard [Fri, 16 Jun 2017 09:33:35 +0000 (09:33 +0000)]
ppc64 doesn't compile test_isa_2_06_partx.c without VSX support
The #ifdef HAS_VSX guard is wrongly placed. It makes the standard
include headers not be used. Causing a build failure. Fix by moving
the #ifdef HAS_VSX after the standard includes.
Mark Wielaard [Tue, 6 Jun 2017 09:03:03 +0000 (09:03 +0000)]
Fix pub_tool_basics.h build issue with g++ 4.4.7.
g++ 4.4.7 doesn't accept union field initializers:
In file included from ../../include/pub_tool_vki.h:50,
from valgrind_cpp_test.cpp:13:
../../include/vki/vki-linux.h: In function ‘vki_cmsghdr* __vki_cmsg_nxthdr(void*, __vki_kernel_size_t, vki_cmsghdr*)’:
../../include/vki/vki-linux.h:673: error: expected primary-expression before ‘.’ token
Assign value after declaration which works for any g++ version.
Julian Seward [Thu, 1 Jun 2017 05:46:54 +0000 (05:46 +0000)]
Back out r16414 (Enable fair scheduling by default on Linux.) following
further investigations showing large performance losses in some case, and no
obvious way to fix the problem.
projects / thirdparty / valgrind.git / log
