Older gcc (4.8) default to GNU C90. Causing:
dlclose_leak.c:14:5: error: ‘for’ loop initial declarations are only
allowed in C99 mode
Fix by declaring int i before the loop.
As reported by Matthias Schwarzott <zzam@gentoo.org>. Testcase patch from him. The fix is
for check_CFSI_related_invariants() to avoid checking for overlaps against DebugInfos that are
in 'archived' status, since -- if a previously dlopened-and-then-dlclosed object is later
re-dlopened -- this may cause an overlap between the active and archived DebugInfos, which
is of no consequence. If the kernel maps the object to the same VMA the second time around
then there will *certainly* be an overlap.
Previous commit (cceed053ce876560b9a7512125dd93c7fa059778) broke the build
for MIPS architecture.
Update the code in VG_(get_StackTrace_wrk) to reflect the changes made in
the previous commit.
(from bug 385408 comment 0):
Valgrind currently lacks support for the z/Architecture vector "support"
instructions introduced with z13. These are documented in the
z/Architecture Principles of Operation, Eleventh Edition (March, 2015),
chapter 21: "Vector Overview and Support Instructions".
Bug 387664 changes the default settings for accurate definedness checking
for {Add,Sub}{32,64} and {CmpEQ,CmpNE}{8,16,32,64}. This fix updates the
vbit tester (memcheck/tests/vbit-test) to test the accurate versions of
these, and thereby fixes a regression caused by
e847cb5429927317023d8410c3c56952aa47fb08 as committed for bug 387664.
https://bugs.kde.org/show_bug.cgi?id=387773
The path to the alt file is relative to the actual debug file.
Make sure that we got the real file, not a (build-id) symlink.
Also handle the case where a debug or alt file is an absolute path.
https://bugs.kde.org/show_bug.cgi?id=387712
When the cgij "compare immediate and branch relative" instruction
compares 0 <=signed dep1, that means dep1 >=signed 0, so it is a test
against the most significant bit of dep1. So only that bit needs
to be defined.
Memcheck tries to accurately track definedness at the bit level, at least
for scalar integer operations. For many operations it is good enough to use
approximations which may overstate the undefinedness of the result of an
operation, provided that fully defined inputs still produce a fully defined
output. For example, the standard analysis for an integer add is
Add#(x#, y#) = Left(UifU(x#, y#))
which (as explained in the USENIX 05 paper
http://valgrind.org/docs/memcheck2005.pdf) means: for an add, worst-case
carry propagation is assumed. So all bits to the left of, and including,
the rightmost undefined bit in either operand, are assumed to be undefined.
As compilers have become increasingly aggressive, some of these
approximations are no longer good enough. For example, LLVM for some years
has used Add operations with partially undefined inputs, when it knows that
the carry propagation will not pollute important parts of the result.
Similarly, both GCC and LLVM will generate integer equality comparisons with
partially undefined inputs in situations where it knows the result of the
comparison will be defined. In both cases, Memcheck's default strategies
give rise to false uninitialised-value errors, and the problem is getting
worse as time goes by.
Memcheck already has expensive (non-default) instrumentation for integer
adds, subtracts, and equality comparisons. Currently these are only used if
you specify --expensive-definedness-checks=yes, and in some rare cases to do
with inlined string operations, as determined by analysing the block to be
instrumented, and by default on MacOS. The performance hit from them can be
quite high, up to 30% lossage.
This patch makes the following changes:
* During instrumentation, there is much finer control over which IROps get
expensive instrumentation. The following groups can now be selected
independently for expensive or cheap instrumentation:
Iop_Add32
Iop_Add64
Iop_Sub32
Iop_Sub64
Iop_CmpEQ32 and Iop_CmpNE32
Iop_CmpEQ64 and Iop_CmpNE64
This makes it possible to only enable, on a given platform, only the minimal
necessary set of expensive cases.
* The default set of expensive cases can be set on a per-platform basis.
This is set up in the first part of MC_(instrument).
* There is a new pre-instrumentation analysis pass. It identifies Iop_Add32
and Iop_Add64 uses for which the expensive handling will give the same
results as the cheap handling. This includes all adds that are used only
to create memory addresses. Given that the expensive handling of adds is,
well, expensive, and that most adds merely create memory addresses, this
more than halves the extra costs of expensive Add handling.
* The pre-existing "bogus literal" detection (0x80808080, etc) pass
has been rolled into the new pre-instrumentation analysis.
* The --expensive-definedness-checks= flag has been changed. Before, it
had two settings, "no" and "yes", with "no" being the default. Now, it
has three settings:
no -- always use the cheapest handling
auto -- use the minimum set of expensive handling needed to get
reasonable results on this platform, and perform
pre-instrumentation analysis so as to minimise the costs thereof
yes -- always use the most expensive handling
The default setting is now "auto". The user-visible effect of the new
default is that there should (hopefully) be a drop in false positive rates
but (unfortunately) also some drop in performance.
Memcheck reports an error on "if (n == 42)" in this test. Unless, that is,
accurate CmpEQ/NE definedness tracking is enabled. If you stare at this
long enough it is possible to see that the test "n == 42" isn't actually
undefined, because |n| is only ever zero or one, and only its least
significant bit is undefined. So the equality comparison against 42 is
defined because there are corresponding bits in the two operands that are
different and are both defined.
This commit fixes that by comparing with 1, which forces the result to
really depend on the only undefined bit in |n|.
I also added robustification:
* return arbitrary values from gcc_cant_inline_me(), so as to avoid gcc
simply copying the input to the output or otherwise deleting the
conditional branch.
* marking gcc_cant_inline_me() as un-inlineable
* Putting compiler barriers in the second conditional in main(), so gcc
can't simply ignore the result of the call to gcc_cant_inline_me() and
then delete the call entirely.
LLVM 5.0 appears to have started generating such constructions in order to
find out whether the top N bits of a value are all zero. This currently
generates Iop_CmpLE32U on partially uninitialised data, causing false
positives in Memcheck. It seems simplest and most efficient to remove such
constructions at this point.
Rearrange big sections in mc_translate.c, so that the "main" instrumentation
function is at the end of the file rather than in the middle. The previous
layout never made much sense. The new layout is, roughly:
* stuff for baseline (level 2, non-origin tracking) instrumentation
* stuff for origin tracking (level 3) instrumentation
* the "final tidying" pass
* the main instrumentation function (and soon, a new pre-instrumentation
analysis pass)
so that e.g.
valgrind -v date
produces
==7639== Using Valgrind-3.14.0.GIT-c470e0c23c-20171120X and LibVEX; rerun with -h for copyright info
to give the verbose version.
Delay writing to the global vgdb_interrupted_tid until all the threads are
in interruptible state. This ensures that valgrind_wait() will see correct
value.
This solves occasional failures of gdbserver_tests/hgtls test.
Helgrind (and incidentally exp-sgcheck) does not need both of
tracking new mem stack and die mem stack:
Helgrind only tracks new mem stack. exp-sgcheck only tracks die mem stack.
Currently, m_translate.c vg_SP_update_pass inserts helpers calls
for new and die mem stack, even if the tool only needs new mem stack (helgrind)
or die mem stack (exp-sgcheck).
The optimisation consists in not inserting helpers calls when the tool
does not need to see new (or die) mem stack.
Also, for helgrind, implement specialised new_mem_stack for known SP updates
with small values (like memcheck).
This reduces the size of the generated code for helgrind and exp-sgcheck.
(see below the diffs on perf/memrw). This does not impact the code generation
for tools that tracks both new and die mem stack (such as memcheck).
trunk:
exp-sgcheck: --28481-- transtab: new 2,256 (44,529 -> 581,402; ratio 13.1) [0 scs] avg tce size 257
helgrind: --28496-- transtab: new 2,299 (46,667 -> 416,575; ratio 8.9) [0 scs] avg tce size 181
memcheck: --28501-- transtab: new 2,220 (50,038 -> 777,139; ratio 15.5) [0 scs] avg tce size 350
with this patch:
exp-sgcheck: --28516-- transtab: new 2,254 (44,479 -> 567,196; ratio 12.8) [0 scs] avg tce size 251
helgrind: --28512-- transtab: new 2,297 (46,620 -> 399,799; ratio 8.6) [0 scs] avg tce size 174
memcheck: --28507-- transtab: new 2,219 (49,991 -> 776,028; ratio 15.5) [0 scs] avg tce size 349
More in details, the changes consist in:
pub_core_tooliface.h:
* add 2 booleans any_new_mem_stack and any_die_mem_stack to the tdict struct
* renamed VG_(sanity_check_needs) to VG_(finish_needs_init), as it
does now more than sanity checks : it derives the 2 above booleans.
m_tooliface.c:
* change VG_(sanity_check_needs) to VG_(finish_needs_init)
m_main.c:
* update call to VG_(sanity_check_needs)
hg_main.c:
* add a few inlines for functions just calling another function
* define the functions evh__new_mem_stack_[4|8|12|16|32|112|128|144|160]
(using the macro DCL_evh__new_mem_stack).
* call the VG_(track_new_mem_stack_[4|8|12|16|32|112|128|144|160])
m_translate.c
* n_SP_updates_* stats are now maintained separately for the new and die
fast and known cases.
* need_to_handle_SP_assignment can now check only the 2 booleans
any_new_mem_stack and any_die_mem_stack
* DO_NEW macro: does not insert anymore a helper call if the tool does
not track 'new' mem_stack.
In case there is no new tracking, it however still does update the
SP aliases (and the n_SP_updates_new_fast).
* similar changes for DO_DIE macro.
* a bunch of white spaces changes
Note: it is easier to look at the changes in this file using
git diff -w
to ignore the white spaces changes (e.g. due to DO_NEW/DO_DIE indentation
changes).
regtested on debian/amd64 and on centos/ppc64
* Some RCEC related asserts checking there was no corruption are on hot paths
=> make these checks only when CHECK_CEM is set.
* Move an expensive assert where the event is inserted, as it is useless
to check this when searching for an already existing event :
it is enough to ensure that an invalid szB cannot be inserted,
and so will not be found, and so assert will trigger in the insertion logic.
When compiling guest_s390_toIR.c for a 32-bit target (a configuration in which
it will never be used, but never mind), gcc-7.x notices that sizeof(ss.dec) is
larger than sizeof(ss.bytes), so the initialisation of ss.bytes leaves ss.dec.b2
and ss.dec.d2 uninitialised. This patch causes both variants to be initialised.
When built for a 64 bit target, the existing initialisation of ss.bytes covers
ss.dec completely, so there is no error.
Searching if an addr is in a malloc-ed client block is expensive (linear search)
So, before scanning the list of malloc block, check that the address is
in a client heap segment : this is a fast operation (it has a small
cache, and for cache miss, does a dichotomic search) and avoids
scanning a often big list (for big applications).
Bits 18 (NAN2008) and 19 (ABS2008) in FCSR are preset by hardware and can
differ between platforms. Hence, we should clear these bits before printing
FCSR value in order to have the same output on different platforms.
This fixes several failures (tests modified by this change) that occur on
MIPS P5600 board. The P5600 is a core that implements MIPS32 Release 5 arch.
This patch implements the flag --delta-stacktrace=yes/no.
Yes indicates to calculate the full history stack traces by
changing just the last frame if no call/return instruction was
executed.
This can speed up helgrind by up to 25%.
This flags is currently set to yes only on linux x86 and amd64, as some
platform dependent validation of the used heuristics is needed before
setting the default to yes on a platform. See function check_cached_rcec_ok
in libhb_core.c for more details about how to validate/check the behaviour
on a new platform.
Under specific circumstances, setting 2048 as a size of symbol of unknown
size causes that symbol crosses unmapped region. This further causes an
assertion in Valgrind.
Compute possible size by computing maximal size the symbol can have within
its section.
Patch by Tamara Vlahovic.
This set of tests covers the whole MSA instruction set:
none/tests/mips32/msa_arithmetic
none/tests/mips32/msa_comparison
none/tests/mips32/msa_data_transfer
none/tests/mips32/msa_fpu
none/tests/mips32/msa_logical_and_shift
none/tests/mips32/msa_shuffle
none/tests/mips64/msa_arithmetic (symlink to mips32)
none/tests/mips64/msa_comparison (symlink to mips32)
none/tests/mips64/msa_data_transfer
none/tests/mips64/msa_fpu (symlink to mips32)
none/tests/mips64/msa_logical_and_shift (symlink to mips32)
none/tests/mips64/msa_shuffle (symlink to mips32)
Contributed by:
Tamara Vlahovic, Aleksandar Rikalo and Aleksandra Karadzic.
Related BZ issue - #382563.
Detect presence of MSA capabilities.
Contributed by:
Tamara Vlahovic, Aleksandar Rikalo and Aleksandra Karadzic.
Minor code-style rewrites by myself.
Related BZ issue - #382563.
New Iops are defined:
Iop_Scale2_32Fx4, Iop_Scale2_64Fx2,
Iop_Log2_32Fx4, Iop_Log2_64Fx2,
Iop_F32x4_2toQ16x8, Iop_F64x2_2toQ32x4,
Iop_PackOddLanes8x16, Iop_PackEvenLanes8x16,
Iop_PackOddLanes16x8, Iop_PackEvenLanes16x8,
Iop_PackOddLanes32x4, Iop_PackEvenLanes32x4.
Contributed by:
Tamara Vlahovic, Aleksandar Rikalo and Aleksandra Karadzic.
Related BZ issue - #382563.
glibc doesn't guarantee anything about setrlimit with a NULL limit argument.
It could just crash (if it needs to adjust the limit) or might silently
succeed (as newer glibc do). Just remove the extra check.
See also the "setrlimit change to prlimit change in behavior" thread:
https://sourceware.org/ml/libc-alpha/2017-10/threads.html#00830
glibc ld.so has an optimization when resolving a symbol that checks
whether or not the upper 128 bits of the ymm registers are zero. If
so it uses "cheaper" instructions to save/restore them using the xmm
registers. If those upper 128 bits contain undefined values memcheck
will issue an Conditional jump or move depends on uninitialised value(s)
warning whenever trying to resolve a symbol.
This triggers in our sh-mem-vecxxx test cases. Suppress the warning
by default.
https://bugs.kde.org/show_bug.cgi?id=385868
Use MIPSRH_Reg to get MIPSRH for Iop_Max32U. Without it, under specific
circumstances, the code may explode and exceed Valgrind instruction buffer
due to multiple calls to iselWordExpr_R through iselWordExpr_RH.
Issue discovered while testing Valgrind on Android.
Patch by Tamara Vlahovic.
While handling Iex_ITE, do not use the same virtual register for the
input and output.
Issue discovered while testing Valgrind on Android.
Patch by Tamara Vlahovic.
Reg<->Reg MOV coalescing status is now a part of the HRegUsage.
This allows register allocation to query it two times without incurring
a performance penalty. This in turn allows to better keep track of
vreg<->vreg MOV coalescing so that all vregs in the coalesce chain
get the effective |dead_before| of the last vreg.
A small performance improvement has been observed because this allows
to coalesce even spilled vregs (previously only assigned ones).
