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
in case the field holds a 32-bit floating point value.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13413
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 definedness check and possible shadow temp set-to-defined be
optional. Use this to properly instrument IRLoadG and IRStoreG, so
that if the load/store does not happen, not only is the validity of
the address not checked, neither is the definedness.
This fixes a regression introduced by the COMEM branch on ARM, in
which conditional loads/stores with addresses which are undefined at
runtime and with guards which are false, would generate false errors.
Also extensively re-checked the check-generation machinery and updated
a bunch of comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13386
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
* when SEGV trapped, report the main thread size as an unsigned size_t
* Similar for memcheck overlap errors
For example, for the 2 calls:
memcpy(&a, &a, 2147483648UL);
memcpy(&a, &a, -1); // silently accepted by gcc 4.4.4 -Wall
// while the 3rd arg is supposed to be a size_t
we now obtain (on a 32 bit system)
Source and destination overlap in memcpy(0xbe97113f, 0xbe97113f, 2147483648)
Source and destination overlap in memcpy(0xbef6d13f, 0xbef6d13f, 4294967295)
instead of
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -2147483648)
Source and destination overlap in memcpy(0xbe8e012f, 0xbe8e012f, -1)
Do not ask me why
memcpy(&a, &a, -1);
is supposed to be accepted/acceptable/valid code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13326
* 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
Necessary changes to Valgrind to support MIPS64LE on Linux.
Minor cleanup/style changes embedded in the patch as well.
The change corresponds to r2687 in VEX.
Patch written by Dejan Jevtic and Petar Jovanovic.
More information about this issue:
https://bugs.kde.org/show_bug.cgi?id=313267
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13292
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
functions to indicate a "true" expression. That caused some confusion
and led people to believe believe, that IRDirty::guard could be NULL.
It cannot.
This confusion was indirectly spotted by coverity's checker who figured
out that IRDirty::guard was sometimes unconditionally dereferenced
and sometimes compared against NULL.
Cleaning this up...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13250
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
