Julian Seward [Tue, 12 Mar 2019 17:37:15 +0000 (18:37 +0100)]
VEX/auxprogs/genoffsets.c: Add cast to my_offsetof. n-i-bz.
Clang/LLVM trips over my_offsetof in VEX/auxprogs/genoffsets.c. See LLVM
PR 40890 for details (https://bugs.llvm.org/show_bug.cgi?id=40890).
Now, it's a Clang bug that Clang exits on an assertion failure rather than
emits a diagnostic, but the previous my_offsetof expression is a pointer,
not an integer. Add a cast as done in other definitions of offsetof in
the tree. Patch from Ed Maste <emaste@freebsd.org>.
Rhys Kidd [Sat, 2 Feb 2019 23:22:16 +0000 (18:22 -0500)]
macOS: Don't duplicate -fno-stack-protector
Since f38d96d -fno-stack-protector has been added to $(AM_CFLAGS_BASE) on all
platforms, if the compiler supports it. Accordingly, there's no need to still add
this a second time specifically for macOS.
Fixes: f38d96d ("Add -Wformat -Wformat-security to the list of compile flags.") Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Rhys Kidd [Thu, 31 Jan 2019 03:52:07 +0000 (22:52 -0500)]
config: remove unrequired AC_HEADER_STDC
Autoconf says:
"This macro is obsolescent, as current systems have conforming
header files. New programs need not use this macro".
Was previously required to ensure the system has C header files conforming
to ANSI C89 (ISO C90). Specifically, this macro checks for stdlib.h,
stdarg.h, string.h, and float.h.
This autoconf option was used to provide conditional fallback support
via defined STDC_HEADERS.
valgrind does not utilize conditional fallback support so, so this macro
is both obsolete and unused, so let's drop it.
Petar Jovanovic [Mon, 4 Mar 2019 18:24:55 +0000 (19:24 +0100)]
modify massif/tests/mmapunmap.vgtest to comply with glibc change
The change in the glibc version (2.27 -> 2.28) results in one additional
function call being present in the backtrace for mips64, which leads to the
line to be checked to be out of bounds.
Changed the post line in mmapunmap.vgtest to work around this.
This fixes massif/tests/mmapunmap failure on mips64.
Mark Wielaard [Thu, 21 Feb 2019 16:21:53 +0000 (17:21 +0100)]
memcheck powerpc subfe x, x, x initializes x to 0 or -1 based on CA
GCC might use subfe x, x, x to initialize x to 0 or -1, based on
whether the carry flag is set. This happens in some cases when g++
compiles resetting a unique_ptr. The "trick" used by the compiler is
that it can AND a pointer with the register x (now 0x0 or 0xffffffff)
to set something to NULL or to the given pointer.
subfe is implemented as rD = (log not)rA + rB + XER[CA]
if we instead implement it as rD = rB - rA - (XER[CA] ^ 1)
then memcheck can see that rB and Ra cancel each other out if they
are the same.
Carl Love [Tue, 5 Feb 2019 16:15:09 +0000 (10:15 -0600)]
Fix missed changes from Rename some int<->fp conversion IROps patch
The previous commit 6b16f0e2a0427f57fb5dc76cbe9177ee35f997ab dated
Sat Jan 26 17:38:01 2019 by Julian Seward <jseward@acm.org> renamed some of
the int<->fp conversion Iops to add a trailing _DEP. The patch missed
renaming two of the Iops. This patch renames the missed Iops.
This commit thoroughly overhauls DHAT, moving it out of the
"experimental" ghetto. It makes moderate changes to DHAT itself,
including dumping profiling data to a JSON format output file. It also
implements a new data viewer (as a web app, in dhat/dh_view.html).
The main benefits over the old DHAT are as follows.
- The separation of data collection and presentation means you can run a
program once under DHAT and then sort the data in various ways. Also,
full data is in the output file, and the viewer chooses what to omit.
- The data can be sorted in more ways than previously. Some of these
sorts involve useful filters such as "short-lived" and "zero reads or
zero writes".
- The tree structure view avoids the need to choose stack trace depth.
This avoids both the problem of not enough depth (when records that
should be distinct are combined, and may not contain enough
information to be actionable) and the problem of too much depth (when
records that should be combined are separated, making them seem less
important than they really are).
- Byte and block measures are shown with a percentage relative to the
global count, which helps gauge relative significance of different
parts of the profile.
- Byte and blocks measures are also shown with an allocation rate
(bytes and blocks per million instructions), which enables comparisons
across multiple profiles, even if those profiles represent different
workloads.
- Both global and per-node measurements are taken at the global heap
peak ("At t-gmax"), which gives Massif-like insight into the point of
peak memory use.
- The final/liftimes stats are a bit more useful than the old deaths
stats. (E.g. the old deaths stats didn't take into account lifetimes
of unfreed blocks.)
- The handling of realloc() has changed. The sequence `p = malloc(100);
realloc(p, 200);` now increases the total block count by 2 and the
total byte count by 300. Previously it increased them by 1 and 200.
The new handling is a more operational view that better reflects the
effect of allocations on performance. It makes a significant
difference in the results, giving paths involving reallocation (e.g.
repeated pushing to a growing vector) more prominence.
Other things of note:
- There is now testing, both regression tests that run within the
standard test suite, and viewer-specific tests that cannot run within
the standard test suite. The latter are run by loading
dh_view.html?test=1 in a web browser.
- The commit puts all tool lists in Makefiles (and similar files) in the
following consistent order: memcheck, cachegrind, callgrind, helgrind,
drd, massif, dhat, lackey, none; exp-sgcheck, exp-bbv.
- A lot of fields in dh_main.c have been given more descriptive names.
Those names now match those used in dh_view.js.
Julian Seward [Thu, 31 Jan 2019 06:56:26 +0000 (07:56 +0100)]
s390 back end: s390_isel_vec_expr_wrk: fix some enum type confusion. n-i-bz.
In s390_isel_vec_expr_wrk() there has been some assignments of enum-typed
values to variables of different enum types. This fixes it. It also adds a
few initialisations to variables of type HReg for safety against the
possibility of them being used uninitialised. No functional change. Tested
by Andreas Arnez.
Rhys Kidd [Tue, 29 Jan 2019 06:07:09 +0000 (01:07 -0500)]
memcheck,macos: Fix vbit-test building on macOS x86 architectures. n-i-bz.
Secondary architectures on macOS are generally x86, which requires additional
LDFLAGS to be set to avoid linker errors.
apple clang (clang-800.0.42.1) error:
ld: illegal text-relocation to '___stderrp' in /usr/lib/libSystem.dylib from '_main'
in vbit_test_sec-main.o for architecture i386
Fixes: 49ca185 ("Also test memcheck/tests/vbit-test on any secondary arch.") Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Fix callgrind_annotate Use of uninitialized value in numeric gt (>)
When a callgrind dump file contains no event (at all I think),
then callgrind_annotate can produce the below error messages:
Ir sysCount sysTime file:function
--------------------------------------------------------------------------------
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
. . . /build/glibc-yWQXbR/glibc-2.24/csu/../csu/libc-start.c:(below main) [/lib/x86_64-linux-gnu/libc-2.24.so]
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
. . . /build/glibc-yWQXbR/glibc-2.24/elf/../sysdeps/x86_64/dl-trampoline.h:_dl_runtime_resolve_xsave [/lib/x86_64-linux-gnu/ld-2.24.so]
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
.....
The above can be produced by:
run sleep 100 under callgrind.
take some callgrind dumps after the startup.
./Inst/bin/callgrind_annotate --threshold=1 callgrind.out.31377.2
Check that the value is defined before doing the comparison.
Note: callgrind_annotate shows functions which have undefined costs
for all events (and I guess it would also show functions that have zero
costs for all events).
Maybe it would be better to not show at all such functions, rather than
show them with all '.'.
Julian Seward [Sat, 26 Jan 2019 16:38:01 +0000 (17:38 +0100)]
Rename some int<->fp conversion IROps for consistency. No functional change. n-i-bz.
2018-Dec-27: some of int<->fp conversion operations have been renamed so as to
have a trailing _DEP, meaning "deprecated". This is because they don't
specify a rounding mode to be used for the conversion and so are
underspecified. Their use should be replaced with equivalents that do specify
a rounding mode, either as a first argument or using a suffix on the name,
that indicates the rounding mode to use.
Julian Seward [Fri, 25 Jan 2019 11:06:37 +0000 (12:06 +0100)]
VG_(discard_translations): try to avoid invalidating the entire VG_(tt_fast) cache. n-i-bz.
It is very commonly the case that a call to VG_(discard_translations) results
in the discarding of exactly one superblock. In such cases, it's much cheaper
to find and invalidate the VG_(tt_fast) cache entry associated with the block,
than it is to invalidate the entire cache, because
(1) invalidating the fast cache is expensive, and
(2) repopulating the fast cache after invalidation is even more expensive.
For QEMU, which intensively invalidates individual translations (presumably
due to patching them), this reduces the fast-cache miss rate from circa one in
33 lookups to around one in 130 lookups.
Julian Seward [Fri, 25 Jan 2019 08:27:23 +0000 (09:27 +0100)]
Bug 402781 - Redo the cache used to process indirect branch targets.
Implementation for x86-solaris and amd64-solaris. This completes the
implementations for all targets. Note these two are untested because I don't
have any way to test them.
Julian Seward [Fri, 25 Jan 2019 08:14:56 +0000 (09:14 +0100)]
Bug 402781 - Redo the cache used to process indirect branch targets.
[This commit contains an implementation for all targets except amd64-solaris
and x86-solaris, which will be completed shortly.]
In the baseline simulator, jumps to guest code addresses that are not known at
JIT time have to be looked up in a guest->host mapping table. That means:
indirect branches, indirect calls and most commonly, returns. Since there are
huge numbers of these (often 10+ million/second) the mapping mechanism needs
to be extremely cheap.
Currently, this is implemented using a direct-mapped cache, VG_(tt_fast), with
2^15 (guest_addr, host_addr) pairs. This is queried in handwritten assembly
in VG_(disp_cp_xindir) in dispatch-<arch>-<os>.S. If there is a miss in the
cache then we fall back out to C land, and do a slow lookup using
VG_(search_transtab).
Given that the size of the translation table(s) in recent years has expanded
significantly in order to keep pace with increasing application sizes, two bad
things have happened: (1) the cost of a miss in the fast cache has risen
significantly, and (2) the miss rate on the fast cache has also increased
significantly. This means that large (~ one-million-basic-blocks-JITted)
applications that run for a long time end up spending a lot of time in
VG_(search_transtab).
The proposed fix is to increase associativity of the fast cache, from 1
(direct mapped) to 4. Simulations of various cache configurations using
indirect-branch traces from a large application show that is the best of
various configurations. In an extreme case with 5.7 billion indirect
branches:
* The increase of associativity from 1 way to 4 way, whilst keeping the
overall cache size the same (32k guest/host pairs), reduces the miss rate by
around a factor of 3, from 4.02% to 1.30%.
* The use of a slightly better hash function than merely slicing off the
bottom 15 bits of the address, reduces the miss rate further, from 1.30% to
0.53%.
Overall the VG_(tt_fast) miss rate is almost unchanged on small workloads, but
reduced by a factor of up to almost 8 on large workloads.
By implementing each (4-entry) cache set using a move-to-front scheme in the
case of hits in ways 1, 2 or 3, the vast majority of hits can be made to
happen in way 0. Hence the cost of having this extra associativity is almost
zero in the case of a hit. The improved hash function costs an extra 2 ALU
shots (a shift and an xor) but overall this seems performance neutral to a
win.
Andreas Arnez [Mon, 21 Jan 2019 13:10:00 +0000 (14:10 +0100)]
Bug 403552 s390x: Fix vector facility bit number
The wrong bit number was used when checking for the vector facility. This
can result in a fatal emulation error: "Encountered an instruction that
requires the vector facility. That facility is not available on this
host."
In many cases the wrong facility bit was usually set as well, hence
nothing bad happened. But when running Valgrind within a Qemu/KVM guest,
the wrong bit was not (always?) set and the emulation error occurred.
This fix simply corrects the vector facility bit number, changing it from
128 to 129.
Fix false positive 'Conditional jump or move' on amd64 64 bits ptracing 32 bits.
PTRACE_GET_THREAD_AREA is not handled by amd64 linux syswrap, which leads
to false positive errors in 64 bits program ptrace-ing 32 bits processes.
For example, the below error was wrongly reported on GDB:
==25377== Conditional jump or move depends on uninitialised value(s)
==25377== at 0x8A1D7EC: td_thr_get_info (td_thr_get_info.c:35)
==25377== by 0x526819: thread_from_lwp(thread_info*, ptid_t) (linux-thread-db.c:417)
==25377== by 0x5281D4: thread_db_notice_clone(ptid_t, ptid_t) (linux-thread-db.c:442)
==25377== by 0x51773B: linux_handle_extended_wait(lwp_info*, int) (linux-nat.c:2027)
....
==25377== Uninitialised value was created by a stack allocation
==25377== at 0x69A360: x86_linux_get_thread_area(int, void*, unsigned int*) (x86-linux-nat.c:278)
Fix this by implementing PTRACE_GET|SET_THREAD_AREA on amd64.
Mark Wielaard [Mon, 31 Dec 2018 21:26:31 +0000 (22:26 +0100)]
Bug 402519 - POWER 3.0 addex instruction incorrectly implemented
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.
Some more .exp changes following --show-error-list new option
A few .exp files (not tested on amd64) have to be changed to
have the messages in the new order:
Use --track-origins=yes to see where uninitialised values come from
For lists of detected and suppressed errors, rerun with: -s
This option allows to list the detected errors and show the used
suppressions without increasing the verbosity.
Increasing the verbosity also activates a lot of messages that
are often not very useful for the user.
So, this option allows to see the list of errors and used suppressions
independently of the verbosity.
Note if a high verbosity is selected, the behaviour is unchanged.
In other words, when specifying -v, the list of detected errors
and the used suppressions are still shown, even if
--show-error-list=yes and -s are not used.
Factorize producing the 'For counts of detected and suppressed errors' msg
Each tool producing errors had identical code to produce this msg.
Factorize the production of the message in m_main.c
This prepares the work to have a specific option to show the list
of detected errors and the count of suppressed errors.
This has a (small) visible effect on the output of memcheck:
Instead of producing
For counts of detected and suppressed errors, rerun with: -v
Use --track-origins=yes to see where uninitialised values come from
memcheck now produces:
Use --track-origins=yes to see where uninitialised values come from
For counts of detected and suppressed errors, rerun with: -v
i.e. the track origin and counts of errors msg are inverted.
Julian Seward [Sat, 22 Dec 2018 18:01:50 +0000 (19:01 +0100)]
amd64 back end: generate improved SIMD64 code.
For most SIMD operations that happen on 64-bit values (as would arise from MMX
instructions, for example, such as Add16x4, CmpEQ32x2, etc), generate code
that performs the operation using SSE/SSE2 instructions on values in the low
halves of XMM registers. This is much more efficient than the previous scheme
of calling out to helper functions written in C. There are still a few SIMD64
operations done via helpers, though.
Julian Seward [Sat, 22 Dec 2018 17:04:42 +0000 (18:04 +0100)]
amd64 back end: generate better code for 2x64<-->V128 and 4x64<-->V256 transfers ..
.. by adding support for MOVQ xmm/ireg and using that to implement 64HLtoV128,
4x64toV256 and their inverses. This reduces the number of instructions,
removes the use of memory as an intermediary, and avoids store-forwarding
stalls.
Julian Seward [Sat, 22 Dec 2018 06:23:00 +0000 (07:23 +0100)]
amd64 pipeline: generate much better code for pshufb mm/xmm/ymm. n-i-bz.
pshufb mm/xmm/ymm rearranges byte lanes in vector registers. It's fairly
widely used, but we generated terrible code for it. With this patch, we just
generate, at the back end, pshufb plus a bit of masking, which is a great
improvement.
Julian Seward [Mon, 10 Dec 2018 16:18:20 +0000 (17:18 +0100)]
Adjust ppc set_AV_CR6 computation to help Memcheck instrumentation.
* changes set_AV_CR6 so that it does scalar comparisons against zero,
rather than sometimes against an all-ones word. This is something
that Memcheck can instrument exactly.
* in Memcheck, requests expensive instrumentation of Iop_Cmp{EQ,NE}64
by default on ppc64le.
Mark Wielaard [Wed, 19 Dec 2018 19:52:29 +0000 (20:52 +0100)]
PR402134 assert fail in mc_translate.c (noteTmpUsesIn) Iex_VECRET on arm64
This happens when processing openssl aes_v8_set_encrypt_key
(aesv8-armx.S:133). The noteTmpUsesIn () function is new since
PR387664 Memcheck: make expensive-definedness-checks be the default.
It didn't handle Iex_VECRET which is used in the arm64 crypto
instruction dirty handlers.
The sys_ptrace post didn't mark the thread as being in traceme mode.
This occassionally would make the memcheck/tests/linux/getregset.vgtest
testcase fail. With this patch it reliably passes.
Mark Wielaard [Wed, 12 Dec 2018 13:15:28 +0000 (14:15 +0100)]
Mark helper regs defined in final_tidyup before freeres_wrapper call.
In final_tidyup we setup the guest to call the freeres_wrapper, which
will (possibly) call __gnu_cxx::__freeres() and/or __libc_freeres().
In a couple of cases (ppc64be, ppc64le and mips32) this involves setting
up one or more helper registers. Since we setup these guest registers
we should make sure to mark them as fully defined. Otherwise we might
see spurious warnings about undefined value usage if the guest register
happened to not be fully defined before.
Add a --show-percs option to cg_annotate and callgrind_annotate.
Because it's very useful. As part of this, the "percentage of events
annotated" numbers at the bottom of the output is changed to "events
annotated" so that --show-percs doesn't compute a percentage of a
percentage.
Example output lines:
```
4,967,137,442 (100.0%) PROGRAM TOTALS
Mark Wielaard [Fri, 7 Dec 2018 13:01:20 +0000 (14:01 +0100)]
Fix sigkill.stderr.exp for glibc-2.28.
glibc 2.28 filters out some bad signal numbers and returns
Invalid argument instead of passing such bad signal numbers
the kernel sigaction syscall. So we won't see such bad signal
numbers and won't print "bad signal number" ourselves.
Add a new memcheck/tests/sigkill.stderr.exp-glibc-2.28 to catch
this case.
Mark Wielaard [Thu, 6 Dec 2018 19:52:22 +0000 (20:52 +0100)]
Bug 401822 Fix asm constraints for ppc64 jm-vmx jm-insns.c test.
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.
Andreas Arnez [Wed, 5 Dec 2018 16:07:05 +0000 (17:07 +0100)]
Add Emacs configuration files
This adds a configuration file ".dir-locals.el" for Emacs to the topmost
directory of the Valgrind source tree, and another such file to the
directory drd/tests. These files contain per-directory local Emacs
variables.
The following settings are performed:
* The base C style is set to "Linux", indentation is set to 3 columns
per level, the use of tabs for indentation is disabled, and the fill
column is set to 80.
* The source files in drd/tests use 2 instead of 3 columns per indentation
level.
Vadim Barkov [Fri, 5 Oct 2018 10:46:44 +0000 (13:46 +0300)]
Bug 385411 s390x: Tests and internals for z13 vector FP support
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.
Always output all leak kinds in a xtree leak result file.
- The option --xtree-leak=yes (to output leak result in xtree format)
automatically activates the option --show-leak-kinds=all,
as xtree visualisation tools such as kcachegrind can in any case
select what kind of leak to visualise.
Andreas Arnez [Thu, 26 Jul 2018 14:35:24 +0000 (16:35 +0200)]
s390x: More fixes for z13 support
This patch addresses the following:
* Fix the implementation of LOCGHI. Previously Valgrind performed 32-bit
sign extension instead of 64-bit sign extension on the immediate value.
* Advertise VXRS in HWCAP. If no VXRS are advertised, but the program
uses vector registers, this could cause problems with a glibc built with
"-march=z13".