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
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
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13152
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13148
Skip the getregset test for MIPS since we still does not have TRACEHOOK
support in MIPS kernel for it, and that is needed to support PTRACE_GETREGSET.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13145
Valgrind 3.8.1 can work with statically linked lib or alternative
malloc libs.
Ensure FAQ properly describe this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13144
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13143
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.
The patch by Josef Weidendorfer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13136
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13130
