VEX buddy patch is r2617.
Enhance testcase for CEDTR and CEXTR. Adapt vbit tester.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
This is part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13203
tester. This is part of fixing BZ #307113.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13195
Prerequisite should be non existence of a #define (rather than existence of
#undef in the comments).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13192
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13191
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13190
signal on amd64-linux systems.
The amd64 ABI describes the required alignment on function entry
as follows:
"In other words, the value (%rsp − 8) is always a multiple
of 16 when control is transferred to the function entry point.
So we need to 16 byte align and then subtract an extra 8 bytes
to achieve the correct alignment.
Patch from fjgmacc@gmail.com to fix BZ#280114.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13182
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13174
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!
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13173
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13170
guest_s390_toIR.c
Identify a few more duplicate mnemonics to avoid false messages
from the checker.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13168
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.
Fixes#305431. (Mark Wielaard, mjw@redhat.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13160
specification of an extra directory in which to look for debuginfo
objects. Fixes#310792. (Alex Chiang, achiang@canonical.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13154
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
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13153
