individual x86 instructions can be found when instrumenting UCode. However,
EIP is not needed during execution, because the x86 instr addresses are copied
into the cost-centres. So now they INCEIPs are removed during the
instrumentation step once their task is done.
This reduces running times by about 3--7%, and translation sizes by about 9%
(code expansion reduced from about 11x to about 10x).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@550
These are the first of a generic family for calling C functions. CCALL_M_N
calls a function with M word-sized arguments and N word-sized return values
(N == 0 or 1, of course). All stack management is done automatically --
register saving, argument pushing, register restoring. Rough timings show it's
marginally faster (~3%), probably because the instrumentation phase is slightly
simpler and translations are slighly more compact.
It was introduced because the way Cachegrind was calling its helper functions
was not really legitimate -- it involved pushing RealRegs at a point where
RealRegs shouldn't have been used. This flukily worked for Cachegrind, but
caused obscure seg faults when I tried using the same technique for the DIDUCE
stuff. Hence this more general approach.
CCALL_M_N where M+N <= 3 are easy. More args might be done by abusing spare
fields in the UInstr struct, if really necessary. But it's not, yet.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@546
which cause the low-level memory manager to crash. When valgrinding
that's all protected, but not when cachegrinding etc.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@537
for god-knows-why reasons. This causes VG_{READ,WRITE}_MISALIGNED_WORD
to give bus errors. Redefine them to do the obvious byte-by-byte loads/
stores. Fortunately they are not performance critical.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@519
be completely pessimistic if it is encountered during the redundant-flag-
save/restore-elimination pass. This fixes the following mysterious
failure:
insane instruction
27: PUTFL %ecx
valgrind: vg_from_ucode.c:2600 (vgPlain_emit_code): Assertion `sane' failed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@516
so as to free memory allocated by glibc. This reduces the leaks reported
in glibc, but causes a stack of read/write-after-free errors which have
to be suppressed :-(
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@507
The Intel p4 manual suggests inserting a pause instruction in
spin-wait loops as a hint to what the code is doing. In other
respects it acts just like a nop. Pause (0xF3 0x90) currently
causes valgrind to panic. The patch below keeps things running.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@493
the scheduler's jmp_buf is not valid. This might avoid at least some
of the following:
vg_scheduler.c:479 (run_thread_for_a_while): Assertion `trc == 0'
failed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@490
to 4096, to possibly avoid deadlocks under very rare circumstances.
Is fully documented and commented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@479
disappearance. This fixes an assertion failure to do with thread nukage
on fork():
vg_scheduler.c:936 (poll_for_ready_fds):
Assertion `vgPlain_is_valid_tid(tid)' failed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@478
