Julian Seward [Fri, 14 Dec 2012 12:51:08 +0000 (12:51 +0000)]
Add a detailed comment re the situation with checking definedness of
addresses in guarded loads, stores and dirty helpers that access
memory. Fall back to a simpler situation as documented in the
comment, possibly on a temporary basis.
Julian Seward [Fri, 14 Dec 2012 10:30:57 +0000 (10:30 +0000)]
Make memcheck/tests/stpncpy be dependent on the presence/absence of
stpncpy in libc, as determined by a configure test. n-i-bz.
(Mark Wielaard, mjw@redhat.com)
Florian Krohm [Tue, 11 Dec 2012 04:09:43 +0000 (04:09 +0000)]
Generalise S390_INSN_GZERO which only worked on the guest
state to S390_INSN_MZERO which works for any memory location
addressable with base reg + 12-bit displacement.
Florian Krohm [Sun, 9 Dec 2012 17:30:45 +0000 (17:30 +0000)]
Clean up the code for facility detection.
First, use STFLE whenever possible (i.e. for all facilities that
were introduced at the same time STFLE was or later). Turns out,
that is most facilities we're interesting in probing, except long
displacement.
Secondly, remove magic constants denoting facility bits and use
the definition from libvex_s390x_common.h
Thirdly, build up the debugging message that shows the status of
the probed facilities in a generic way so it won't have to be
changed when facilities are added.
Florian Krohm [Sun, 9 Dec 2012 15:39:43 +0000 (15:39 +0000)]
Stop sending z10-ec nightly build messages to valgrind-developers
for two reasons:
(1) Those build logs appear to never have made it
(2) Sourceforge recently started spamming my inbox with
SMTP; 550 This message scored 19.5 points. Congratulations!
Fix 284540 and 307465
284540 Memcheck shouldn't count suppressions matching still-reachable allocations
307465 --show-possibly-lost=no should bring down the error count / exit code
Using the options --show-leak-kinds=kind1,kind2,.. and
--errors-for-leak-kinds=kind1,kind2,.., each leak kind (definite, indirect,
possible, reachable) can now be individually reported and/or counted as
an error.
In a leak suppression entry, an optional line 'match-leak-kinds:'
controls which leak kinds are suppressed by this entry.
This is a.o. useful to avoid definite leaks being "catched"
by a suppression entry aimed at suppressing possibly lost blocks.
Default behaviour is the same as 3.8.1
Old args (--show-reachable and --show-possibly-lost) are still accepted.
Addition of a new test (memcheck/tests/lks) testing the new args
and the new suppression line.
Florian Krohm [Fri, 7 Dec 2012 04:37:53 +0000 (04:37 +0000)]
Identify opcodes that are not handled by the decoder in
guest_s390_toIR.c
Identify a few more duplicate mnemonics to avoid false messages
from the checker.
Julian Seward [Thu, 6 Dec 2012 16:27:18 +0000 (16:27 +0000)]
When looking for a separate debug object, tolerate mismatched phdrs by
instead checking the shdrs:
The separate .debug file has wrong phdrs. This isn't normally fatal
since .debug files are never directly loaded. But since valgrind
uses the phdrs to locate the build-id it will fail. The attached
patch makes it so that the code falls back to using the shdrs to
locate the NOTE sections so that the buildid can be matched anyway.
Julian Seward [Wed, 5 Dec 2012 22:15:14 +0000 (22:15 +0000)]
Add a new command line flag, --extra-debuginfo-path=path, that allows
specification of an extra directory in which to look for debuginfo
objects. Fixes #310792. (Alex Chiang, achiang@canonical.com)
fix 310424 --read-var-info does not properly describe static variables
This patch changes the way static variables are
recorded by readdwarf3.c (when giving --read-var-info=yes),
improving the way such variables are described.
Currently:
A static variable does not have the DW_AT_external tag.
So, readdwarf3.c does not consider it a global variable.
It is rather considered a "local" variable.
When it is recorded, it is associated to a range of program counters
(the functions in the file where it is visible).
However, even if the static variable is only visible
in the source file where it is declared, it can in reality
be used by any range of program counters, typically
by having the address of the local variable passed
to other functions.
Such local variable can then only be described
when the program counter is in the range of program
counters for which it has been recorded.
However, this (local) description is obtained
by a kludge in debuginfo.c (around line 3285).
This kludge then produces a strange description,
telling that the variable has been declared in
frame 0 of a thread (see second example below).
The kludge is not always able to describe
the address (if the IP of the tid is in another file than
where the variable has been declared).
I suspect the kludge can sometimes describe the var as being
declared in an unrelated thread
(e.g. if an error is triggered by tid 5, but tid1 is by
luck in an IP corresponding to the recorded range).
The patch changes the way a static variable is recorded:
if DW_AT_external tag is found, a variable is marked as global.
If a variable is not external, but is seen when level is 1,
then we record the variable as a global variable (i.e.
with a full IP range).
This improves the way such static variable are described:
* they are described even if being accessed by other files.
* their description is not in an artificial "thread frame".
First example:
**************
a variable cannot be described because it is
accessed by a function in another file:
with the trunk:
==20410== ----------------------------------------------------------------
==20410==
==20410== Possible data race during read of size 4 at 0x600F54 by thread #1
==20410== Locks held: none
==20410== at 0x4007E4: a (abc.c:42)
==20410== by 0x4006BC: main (mabc.c:24)
==20410==
==20410== This conflicts with a previous write of size 4 by thread #2
==20410== Locks held: none
==20410== at 0x4007ED: a (abc.c:42)
==20410== by 0x400651: brussels_fn (mabc.c:9)
==20410== by 0x4C2B54E: mythread_wrapper (hg_intercepts.c:219)
==20410== by 0x4E348C9: start_thread (pthread_create.c:300)
==20410==
==20410== ----------------------------------------------------------------
with the patch:
==4515== ----------------------------------------------------------------
==4515==
==4515== Possible data race during read of size 4 at 0x600F54 by thread #1
==4515== Locks held: none
==4515== at 0x4007E4: a (abc.c:42)
==4515== by 0x4006BC: main (mabc.c:24)
==4515==
==4515== This conflicts with a previous write of size 4 by thread #2
==4515== Locks held: none
==4515== at 0x4007ED: a (abc.c:42)
==4515== by 0x400651: brussels_fn (mabc.c:9)
==4515== by 0x4C2B54E: mythread_wrapper (hg_intercepts.c:219)
==4515== by 0x4E348C9: start_thread (pthread_create.c:300)
==4515==
==4515== Location 0x600f54 is 0 bytes inside global var "static_global"
==4515== declared at mabc.c:4
==4515==
==4515== ----------------------------------------------------------------
Second example:
***************
When the kludge can describe the variable, it is strangely described
as being declared in a frame of a thread, while for sure the declaration
has nothing to do with a thread
With the trunk:
==20410== Location 0x600f68 is 0 bytes inside local var "static_global_a"
==20410== declared at abc.c:3, in frame #0 of thread 1
With the patch:
==4515== Location 0x600f68 is 0 bytes inside global var "static_global_a"
==4515== declared at abc.c:3
#include <stdio.h>
static int static_global_a = 0; //// <<<< this is abc.c:3
Fix missing in EXTRA_DIST errors reported by check_makefile_consistency
memcheck/tests/amd64/Makefile.am:1: error: insn-bsfl.stderr.exp is missing in EXTRA_DIST
memcheck/tests/amd64/Makefile.am:1: error: insn-bsfl.stdout.exp is missing in EXTRA_DIST
memcheck/tests/amd64/Makefile.am:1: error: insn-bsfl.vgtest is missing in EXTRA_DIST
memcheck/tests/amd64/Makefile.am:1: error: insn-pcmpistri.stderr.exp is missing in EXTRA_DIST
memcheck/tests/amd64/Makefile.am:1: error: insn-pcmpistri.stdout.exp is missing in EXTRA_DIST
memcheck/tests/amd64/Makefile.am:1: error: insn-pcmpistri.vgtest is missing in EXTRA_DIST
memcheck/tests/amd64/Makefile.am:1: error: insn-pmovmskb.stderr.exp is missing in EXTRA_DIST
memcheck/tests/amd64/Makefile.am:1: error: insn-pmovmskb.stdout.exp is missing in EXTRA_DIST
memcheck/tests/amd64/Makefile.am:1: error: insn-pmovmskb.vgtest is missing in EXTRA_DIST
none/tests/s390x/Makefile.am:1: error: dfp-1.stderr.exp is missing in EXTRA_DIST
none/tests/s390x/Makefile.am:1: error: dfp-1.stdout.exp is missing in EXTRA_DIST
none/tests/s390x/Makefile.am:1: error: dfp-1.vgtest is missing in EXTRA_DIST
Florian Krohm [Tue, 4 Dec 2012 04:45:32 +0000 (04:45 +0000)]
In the past, the implementation of STFLE returned the facilities of the host
machine. This was not consistent in the following sense: Suppose the host
has a facility F installed and this facility implies the availability of an
insn X. Suppose further, that insn X is not supported in valgrind.
An application progrm that tests the availability of insn X by checking
for its associated facility F will fail under valgrind when using X because
valgrind will SIGILL. Not so good.
This patch changes the STFLE behaviour to adjust the facilities of the
virtual machine according to what the set of insns that is actually
supported. It's an approximation, because for some facilities we only
support a subset of the insns enabled by that facility.
Petar Jovanovic [Mon, 3 Dec 2012 00:31:42 +0000 (00:31 +0000)]
Correctly skip memcheck's getregset for MIPS.
Previous change r13145 incorrectly disables getregset test for all architectures
rather than just for MIPS arch. Issue spotted by Bart Van Assche and reported on
the list.
Improve FAQ section discussing statically linked lib
Valgrind 3.8.1 can work with statically linked lib or alternative
malloc libs.
Ensure FAQ properly describe this.
Callgrind, Cachegrind, and Lackey call
helpers for memory accesses in bunches, to reduce
register save/restore overhead (and merge load/store
within same instruction into a "modify" event).
The calls should not be done within a RMW section
enclosed by LL/SC instructions, as this reduces the
chance of SC to succeed, and can result in hangs.
For Callgrind, this definitly helped MIPS, and was
committed in r13136. Do the same for Cachegrind/Lackey.
Julian Seward [Sun, 25 Nov 2012 15:26:48 +0000 (15:26 +0000)]
Initial front changes for ARM, to generate direct IR for at least some
conditional loads and stores. Very incomplete -- most load-store
cases still use the old scheme.
Petar Jovanovic [Fri, 23 Nov 2012 00:44:37 +0000 (00:44 +0000)]
Correctly model LL/SC on MIPS.
As the issue with RMW on MIPS does not block execution anymore (see Valgrind
patch r13136), we can switch back to model it through LoadL and StoreC instead
of using incorrect Load and Store.
This will give back correct output to memcheck/tests/atomic_incs on MIPS.
Petar Jovanovic [Fri, 23 Nov 2012 00:01:36 +0000 (00:01 +0000)]
Flush events in Callgrind before enering a RMW region.
On some MIPS platforms, we had an issue in which SC would fail each time
due to some memory access occuring in the RMW region.
If code for simulator events is called before LL, it can help SC to pass.
This change fixes a few LL/SC issues on MIPS arch.
Carl Love [Tue, 20 Nov 2012 17:32:48 +0000 (17:32 +0000)]
VEX, ppc fix use of modified value in the Iop_32HLto64 implementation
The issue with the Iop_32HLto64, as explained by Julian:
One of the "rules of the game" of instruction selection is that the register
returned by any of the isel* functions may not be modified -- if it needs to
be modified, first copy the value off to a different register. The rule exists
because, in this case, e->Iex.Binop.arg2 might be an IRExpr_RdTmp, in which
case iselWordExpr_R simply returns the register which holds the value of the
relevant IR temporary. And so if r_Lo is modified then any subsequent uses of
that IR temporary will get the wrong value. In this case, r_Lo is
modified without first copying it.
This patch fixes the issue by assigning the result of the AND operation to
a temporary and then using the temporary result in the OR operation thus
avoiding using a modified value.
Julian Seward [Tue, 20 Nov 2012 15:24:24 +0000 (15:24 +0000)]
Add a special-case implementation of PCMPISTRI $0x3A, which generates
in-line IR instead of calling helpers. This is so that Memcheck can
do exact definedness propagation through it. This is important for
dealing with inlined PCMPISTRI-based strlen calls.
#309921, comment 6. (Patrick J. LoPresti , lopresti@gmail.com)
Callgrind: fix Ir cost update for ignored functions
Also without cache simulation, Callgrind maintains Ir cost.
This is done in setup_bbcc by incrementing an execution counter
for last_bbcc (the cost center for the previously executed BB
in current context) and the global cost counter.
However, we forgot to increment any counter if the currently
executing function should be ignored. We need to still update
costs, add attribute this to a not-ignored call site (as
given in CLG_(current_state).nonskipped).
Before this fix, there was a difference in Ir cost with vs. without
cache simulation. This was because ignored functions (e.g. PLT code)
contributed no cost when not doing cache simulation.
Carl Love [Fri, 16 Nov 2012 19:41:21 +0000 (19:41 +0000)]
vbit-tester, add counts for the number of 1, 2, 3 and 4 operand tests.
This patch adds code to count the number of each type of test. The
number of 1, 2, 3 and 4 operand tests that are generated by the vbit-tester
are counted and printed by the vbit-tester. The user should refer to the
Valgrind output to see if any of the tests failed.
The existing two verbose levels was increased by one level and the the
new output giving the number of tests was inserted as the first verbose
level. The verbose levels are now:
-v shows the number of 1, 2, 3 and 4 operand tests that are generated
-v -v shows IROps being tested
-v -v -v extreme edition, shows input values
Carl Love [Fri, 16 Nov 2012 18:58:08 +0000 (18:58 +0000)]
Valgrind, V-bit tester: Add support for Iop_CmpORD class iops
The Iop_CmpORD class of iops support the POWER specific comparison
instructions. The instructions take two 32-bit or 64-bit operands
and produce a result of the same size. However, only the lower bits
of the result are set by the instruction. The bits are set by the instruction
to indicate if the comparison is "less then", "greater then", or "equal".
This patch adds support to the V-bit tester to verify the propagation
of the undefined bits in the inputs to the output for the Iop_CmpORd iops.
The output bits are always set to undefined if any of the input bits are not
defined.
projects / thirdparty / valgrind.git / log
