Fix stupid bug in which vg_push_signal_frame/vg_pop_signal_frame assumed
that the handler wouldn't change the signal-number parameter it was passed.
Fixes this:
vg_signals.c:1065 (vgPlain_signal_returns):
Assertion `sigNo >= 1 && sigNo <= 64' failed.
and possibly arbitrary other mutancy in the signal handling too.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1111
- changed lots of Makefile.am files
- changed configure.in
- changed lots of #include lines for changed file names
- changed lots of file headers n footers for changed file names
- changed vg_regtest to handle new directory structure -- recursively
traverses subdirectories for .vgtest test files
- changed lots of paths in memcheck/ regression test expected outputs
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1090
- Improves the code generation for arithmetic instructions. Some arith
instructions (ADC, SBB, RCR, RCL, some FPU) read EFLAGS -- integer ops for
the carry flag, and FPU for ZCP (sometimes). But the rest don't.
Previously, the EFLAGS register was always being read before any arith
instruction, even those for which it wasn't needed. Now it's only done if
needed. This was done by splitting the anyFlagUse test used into
readFlagUse and writeFlagUse.
This results in reasonable decreases in time (3--5% for Valgrind, 12--14%
with no instrumentation) and size of translations (2%, 5%).
vg_translate.c:
- added CCALL_{1,2}_0 to a comment they were missing from.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@554
the root thread (tid 1) always uses _res as exported from libc.so as its
state. This fixes the name lookup problems in KAtlantik.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@551
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
exposed by scheduling changes caused by commit vg_scheduler.c rev 1.70.
We cannot simply pass the __attr pointer to the child, since it could
point to stuff on the parent's stack, which might not exist by the time
the child looked at it. Prior to scheduler.c rev 1.70 the child would
have been scheduled as soon as created, so the access was made before the
parent could clear the stuff from its stack. From rev 1.70 and after
the parent continues after creating the child, causing invalid stack
accesses when the child finally runs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@455
into one. This can change the scheduling a bit since the policy of
running the same thread after the request if it is possible now applies
to _all_ requests.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@454
