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
found by Coverity's checker.
Also fix another missing break XEN_SYSCTL_numainfo found by via a
by-eye check. This one is at the end of the switch so it is benign.
Patch by Ian Campbell <ian.campbell@citrix.com>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13251
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
One issue has been reported on the mailing list by Ilya Smelykh, and the second
issue has been found in development for MIPS64.
The change modifies the way we detect target-arch by reading host_cpu from
config.log rather than asking the toolchain.
Also, for MIPS64, we use:
--section-start=.MIPS.options=$ala
while for o32 we still use:
--section-start=.reginfo=$ala
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13249
Test program that triggers different corner cases related to position of
branch instruction and max size of a translation block (60 instructions).
Fix for these issues has been submitted in r2648.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13248
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
This generalises the "perm_malloc" function which was in ms_main.c
The new VG_(perm_malloc) is used in ms_main.c
and for execontext : when there are a lot of execontext, this
can save significant memory.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13238
This change is based on rumours/legends/oral transmission of experience/...
that prime nrs are good to use for hash table size :).
If someone has a (short) explanation about why this is useful,
that will be welcome.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13237
Two fixes could be done:
Either we fix the comments
or we increase N_FRAMES to be rather VG_DEEPEST_BACKTRACE.
We fix the comment for the following reason:
This is (at least for the moment) not performance critical.
as this is only called when an error is reported.
However, searching for local vars is extremely costly.
It is unlikely that an error is reported for a stack variable
which is more than 8 frames deeper than theframe in which
it is detected.
So, fix the comment, waiting for a complaint that a deeper
variable is not properly described.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13235
All calls to VG_(unknown_SP_update) were recording an execontext
of one IP, useful only for track origin.
This patch implements splits VG_(unknown_SP_update)
in two different functions VG_(unknown_SP_update_w_ECU)
(doing origin tracking) and VG_(unknown_SP_update) (not doing origin tracking).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13225
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
information about the stack traces recorded by Valgrind.
This can be used to analyse one possible cause of Valgrind high
memory usage for some programs.
At work, a big set of regression tests crashed out of memory under Valgrind.
Two main causes for out of memory were identified:
1. big memory usage for stacktrace (exe contexts) recording by Valgrind
2. big number of partially initialised bytes.
This patch adds a gdbsrv monitor command that output (very) detailed
information about all the recorded exe context.
This has been used to analyse the problem 1. above,
showing the following identified causes for a (too) big nr of execontexts:
A. When the JIT handles an unknown SP update, even when --track-origins=no,
an execontext is (uselessly) created and recorded
to track the (never used) origin of some uninitialised stack memory.
This creates a whole bunch of 'one IP' execontexts.
B. same problem in handling some system calls (at least the brk system
calls always records an origin, even when --track-origins=yes).
C. The Valgrind unwinder cannot properly unwind some stack traces.
It unwinds a few frames, then go bezerk and stops at a "random" IP.
This then causes the same "logical" stacktrace to be truncated
and records thousands of times with this "differentiating" last IP.
For problem cause 2 above ( a lot of partially initialised bytes),
the idea is to similarly add another gdbsrv commands that will output
statistics about which stack traces are causing a lot of uninitialised bytes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13220
--profile-flags=00000000 now prints summary statistics, one line per
profiled block, but with no translation details. Previously it had
no effect.
--profile-interval=<number> is a new flag that causes the profile data
to be dumped and zeroed every <number> event checks. This makes it
possible to get profile data without waiting for runs to end, and to
get profile data which depends on the current workload etc. If
--profile-interval=0 or is unset, the profile is printed only once, at
the end of the run, as before.
--profile-flags=XXXXXXXX (for at least one nonzero X) prints the
summary lines both at the start and end of the profile, so you don't
have to scroll back up to the top to see the summary.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13213
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ #307113.
[ r13211 was also implemented by Maran. ]
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13212
