Florian Krohm [Fri, 21 Dec 2012 18:34:48 +0000 (18:34 +0000)]
Companion patch to VEX r2605. Adds a few testcases and adapts the vbit
tester. This is part of fixing BZ #307113.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Florian Krohm [Fri, 21 Dec 2012 17:32:12 +0000 (17:32 +0000)]
Add support for these DFP insns:
AXTRA, CDTR, CXTR, DXTRA, LDETR, LXDTR, LDXTR, LEDTR, LTXTR, MXTRA, SXTRA
This is part of fixing BZ #307113.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com) with some minor
mods.
Petar Jovanovic [Thu, 20 Dec 2012 19:02:17 +0000 (19:02 +0000)]
Use different incorrect value in pth_detached3
The test pth_detached3 will crash on MIPS platform if the value passed to
pthread_detach is not correctly aligned. Thus, we change the value to be still
invalid but aligned.
This fixes the failure of drd/tests/pth_detached3 on MIPS32.
Petar Jovanovic [Thu, 20 Dec 2012 18:56:57 +0000 (18:56 +0000)]
Introduce DISABLE_PTHREAD_SPINLOCK_INTERCEPT flag
The flag DISABLE_PTHREAD_SPINLOCK_INTERCEPT is set only for MIPS32, and it is
used in DRD and Helgrind as a workaround for the issue #311690.
In short, pthread_spin_lock implementation has local branches to the start of
the function which interferes with the redirection system in Valgrind that
assumes it has to redirect each call/branch to a particular address.
Florian Krohm [Thu, 20 Dec 2012 16:58:52 +0000 (16:58 +0000)]
s390: Fix IR generation for DDTR and MDTR. These insns do not modify
the condition code.
Spotted and fixed by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Julian Seward [Mon, 17 Dec 2012 21:56:58 +0000 (21:56 +0000)]
Instrumentation of guarded loads and stores: annotate helper calls
with the required IRDefault (guarded-dirty-call default return result
specifications).
Julian Seward [Mon, 17 Dec 2012 21:54:10 +0000 (21:54 +0000)]
IR: add the ability to specify the call-didn't-happen ("default")
return value for conditional dirty helper calls returning values. The
default value can be either all-zeroes or all-ones.
Florian Krohm [Sun, 16 Dec 2012 22:49:05 +0000 (22:49 +0000)]
Fix an assert in s390 disassembly. Eliminate a few magic array
width constants and use S390_MAX_MNEMONIC_LEN instead.
New function "mnemonic" to construct a mnemonic string padded with
blanks for alignment.
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.
projects / thirdparty / valgrind.git / log
