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
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
This patch adds code to count the number of each type of test. The
number of 1, 2, 3 and 4 operand tests that are generated by the vbit-tester
are counted and printed by the vbit-tester. The user should refer to the
Valgrind output to see if any of the tests failed.
The existing two verbose levels was increased by one level and the the
new output giving the number of tests was inserted as the first verbose
level. The verbose levels are now:
-v shows the number of 1, 2, 3 and 4 operand tests that are generated
-v -v shows IROps being tested
-v -v -v extreme edition, shows input values
This patch is for bugzilla 309229
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13124
The Iop_CmpORD class of iops support the POWER specific comparison
instructions. The instructions take two 32-bit or 64-bit operands
and produce a result of the same size. However, only the lower bits
of the result are set by the instruction. The bits are set by the instruction
to indicate if the comparison is "less then", "greater then", or "equal".
This patch adds support to the V-bit tester to verify the propagation
of the undefined bits in the inputs to the output for the Iop_CmpORd iops.
The output bits are always set to undefined if any of the input bits are not
defined.
This patch is for bugzilla 310169
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13123
BSF instructions, as the lack of it causes false positives (Valgrind
side). Fixes#308627. (Patrick J. LoPresti <lopresti@gmail.com>)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13108
The 32-bit testsuite executes the 64-bit class instruction prtyd. This
instruction should not be tested in 32-bit mode. The change also updates
the expected output for the test. Note, 32-bit HW will generate a SIGILL
when the prtyd instruction is executed. However, the 64-bit HW executing
a 32-bit application does execute the instruction but only the lower 32-bits
of the result are valid. In general, the 64-bit class instructions should
not be executed in 32-bit binaries.
This fix accompanies the VEX fix in revision 2558 to add the 64-bit mode test
to make sure the 64-bit class instructions are only executed in 64-bit mode.
The VEX bugzilla is:
Bug 308573 - Internal Valgrind error on 64-bit instruction executed in
32-bit mode
Carl Love cel@us.ibm.com
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13091
The test succeeds on amd64, but fails on x86, with the following diff:
+Syscall param semctl(arg) points to uninitialised byte(s)
+ at 0x........: semctl@@GLIBC_2.2 (semctl.c:109)
+ by 0x........: main (sem.c:36)
+ Address 0x........ is on thread 1's stack
+
+Syscall param semctl(arg) points to uninitialised byte(s)
+ at 0x........: semctl@@GLIBC_2.2 (semctl.c:109)
+ by 0x........: main (sem.c:43)
+ Address 0x........ is on thread 1's stack
+
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13073
