Add a function in the memcheck/tests/leak-segv-jmp.c for MIPS64
that execute the syscall. Because we added the mips64 case we
need to change the line number in *.exp file.
Fixes memcheck/tests/leak-segv-jmp for MIPS64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13456
in VEX r2727 (conversion ops between binary floating point and
decimal floating point).
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13428
Line numbers are off by one in some outputs since it differs on GCC version
how it will map source code to line number for the ternary operator written
in multiple lines.
This is small fix that replaces one occurrence of ternary operator with
if-then-else. The excepted outputs have been changed accordingly.
This fixes the test memcheck/tests/cond_ld_st for different platforms with
different GCC versions.
Tested on x86, i386, ARM, MIPS32, and MIPS64.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13415
Bug #320116. sockaddr_rc might contain some padding which might not be
initialized. Explicitly check the sockaddr_rc fields are set. That also
produces better diagnostics about which field is unitialized.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13404
This fixes:
- memcheck/tests/cond_ld and
- memcheck/tests/cond_st
for 32-bit non-ARM architectures. Tested on IA32 and MIPS32.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13401
The replacement functions are running on the simulated CPU.
The code on the simulated CPU does not necessarily use
all arguments. E.g. args can be ignored and/or only given
to a NON SIMD call.
The definedness of such 'unused' arguments will not be verified
by memcheck.
A call to 'trigger_memcheck_error_if_undefined' allows
memcheck to detect such errors for the otherwise unused args.
Apart of allowing memcheck to detect an error, the function
trigger_memcheck_error_if_undefined has no effect and
has a minimal cost for other tools replacing malloc functions.
(suggestion of the 'no operation check' from Julian).
tested on f12/x86, debian6/amd64, f18/ppc64
Note that some Darwin specific code has been modified
in coregrind/m_replace_malloc/vg_replace_malloc.c.
(Some of) this code has not been compiled (no access to a
Darwin system). The code changed is trivial, so there is
some chance it will compile and even maybe work.
Added a new test verifying that various malloc related
functions undefined args are triggering an error in memcheck.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13361
Add mips64-le implementation of:
- atomic_add_8bit
- atomic_add_16bit
- atomic_add_32bit
- atomic_add_64bit
- do_acasW
Minor fixes for mips32 implementations are included as well.
These functions are needed to execute atomic_incs and annotate_hbefore
tests on mips64le.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13357
memcheck/tests/vbit-test fails with unknown opcode after introduction
of new Iops for AVX2, BMI, FMA support #317506
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13347
(problem reported in bug 307082, comment 8).
Solution applied is similar to what is in 307082 patch
(i.e. do not destroy the internal helgrind var if nWaiters > 0).
But also do not remove it from the FM.
+ add a test case (re-using the drd test case)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13329
* avoid a warning related to pointer types
* replace exit (0) by return 0 (might help backtraces on Darwin, suggestion by Rich Coe)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13301
Update vbit tester. Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ #307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13285
causing segfaults with gcc-4.7. The inline assembly still isn't right,
but it's better than it was before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13279
The implementation of integer operands doesn't really match the documentation
for the Iop. Take for example Iop_ExtractExpD64. It is documented as
D64 -> I64 but the implementation of the UNARY is defined as
UNARY(Ity_D64, Ity_D64). The result is an integer that is stored in an integer
format in a floating point register. On the IBM s390 however, the architecture
stores the integer value in a general purpose register (GPR) not a floating
point register. This issue exists with the implementation of 11 Iops where the
PPC implementation has either a source or destination whose value is an integer
but the value is stored in a floating point register in an integer format. After
reviewing the PPC implementation with the s390 developer, it was agreed the
cleanest way to fix this is to change the PPC implementation. The BINOP will be
changed to be consistent with the Iop description. This means the PPC
instruction implementation of the PPC instruction in guest_ppc_toIR.c will need
to reinterpret integer source operands as integers which will move the value
from a floating point register to an integer register before calling binop().
The underlying PPC implementation of the unop() for the specific Iop will also
need to change to move the value from the integer register back to the floating
point register so the native instruction can be issued with the integer value
in a floating point register. It was decided that making the changed in PPC,
rather then having the s390 reinterpret integers as DFP and then move the value
back to an integer register, was preferable as it makes the implementation of
the unop(), binops(), triop() consistent with the definition of the Iop.
This patch also includes the needed changes for the vbit tester. The Iop
definitions in memcheck/tests/vbit-test/util.c had to be updated to be consitent
with the changes in the Iops as documented below. Also, the function mkLazy3()
in memcheck/mc_translate.c had to be updated to handle the I32 x I8 x I64 -> I64
and I32 x I8 x I128 -> I128 cases.
The specific list of changes are as follows:
Iop name in pub/libvex_ir.h
documented type
type of UNARY/BINARY/TERNARY in priv/ir_defs.c
-------------------------------------------------------
Iop_ExtractExpD64
D64 -> I64
UNARY(Ity_D64, Ity_D64); (current)
UNARY(Ity_D64, Ity_I64); (fix)
Iop_ExtractExpD128
D128 -> I64
UNARY(Ity_D128, Ity_D64); (current)
UNARY(Ity_D128, Ity_I64); (fix)
Iop_InsertExpD64
I64 x I64 -> D64
I64 x D64 -> D64 (fix definition)
BINARY(Ity_D64,Ity_D64, Ity_D64); (current)
BINARY(Ity_I64,Ity_D64, Ity_D64); (fix)
Iop_InsertExpD128
I64 x I128 -> D128
I64 x D128 -> D128 (fix definition)
BINARY(Ity_D64,Ity_D128, Ity_D128); (current)
BINARY(Ity_I64,Ity_D128, Ity_D128); (fix)
Iop_I64StoD128
I64S -> D128
UNARY(Ity_D64, Ity_D128); (current)
UNARY(Ity_I64, Ity_D128); (fix)
Iop_D64toI64S
IRRoundingModeDFP(I32) x D64 -> I64
BINARY(ity_RMode, Ity_D64, Ity_D64) (current)
BINARY(ity_RMode, Ity_D64, Ity_I64) (fix)
Iop_D128toI64S
IRRoundingModeDFP(I32) x D128 -> I64
BINARY(ity_RMode, Ity_D128, Ity_D64); (current)
BINARY(ity_RMode, Ity_D128, Ity_I64); (fix)
Iop_I64StoD64
IRRoundingModeDFP(I32) x I64 -> D64
BINARY(ity_RMode, Ity_D64, Ity_D64); (current)
BINARY(ity_RMode, Ity_I64, Ity_D64); (fix)
Iop_SignificanceRoundD64
IRRoundingModeDFP(I32) x I8 x D64 -> D64
TERNARY(ity_RMode,Ity_D64,Ity_D64, Ity_D64); (current)
TERNARY(ity_RMode,Ity_I8,Ity_D64, Ity_D64); (fix)
Iop_SignificanceRoundD128
IRRoundingModeDFP(I32) x I8 x D128 -> D128
TERNARY(ity_RMode,Ity_D128,Ity_D128, Ity_D128); (current)
TERNARY(ity_RMode,Ity_I8,Ity_D128, Ity_D128); (fix)
The patch is for bugzilla 311100
VEX Committed revision 2652
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13260
In a big applications, some recursive algorithms have created
hundreds of thousands of stacktraces, taking a lot of memory.
Option --merge-recursive-frames=<number> tells Valgrind to
detect and merge (collapse) recursive calls when recording stack traces.
The value is changeable using the monitor command
'v.set merge-recursive-frames'.
Also, this provides a new client request: VALGRIND_MONITOR_COMMAND
allowing to execute a gdbsrv monitor command from the client
program.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13246
Adapt vbit-tester.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13224
The option --keep-stacktraces controls which stack trace(s) to keep for
malloc'd and/or free'd blocks. This can be used to obtain more information
for 'use after free' errors or to decrease Valgrind memory and/or cpu usage
by recording less information for heap blocks.
This fixes 312913 Dangling pointers error should also report the alloc
stack trace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13223
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
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
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
