ip before starting a new pass of the loop.
The reason for this is that (except for the first pass of the loop) the
value of ip is actually a return address, which is therefore after the
instruction that was executing at the time. This means that if there is
a boundary in the CFI information at that point we can wind up using the
wrong CFI data to do the next unwind if we do it based on the return
address.
This most commonly happens with a tail call where we wind up using the
data for the next function to do the unwind and getting hopelessly lost.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4996
which are x86 specific. The first three x86 specific ones should
work on amd64 as well so I have added those as amd64 tests.
Note that the x86/amd64 tests will still fail as VEX doesn't
always trigger the right sort of signal for faulting instructions
at the moment.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4992
the old style sigprocmask system call correctly without corrupting
memory when we copy out the new (larger) signal mask into the user
provided old (smaller) signal mask.
It therefore makes no sense to run it on amd64 or any other platform
which only has the newer rt_sigprocmask system call, and indeed it
wasn't working because we weren't passing the extra argument which
that call expects.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4990
simply treating R and X as equivalent but the real problem is that
mappings can appear to have X permission entirely indepenent of anything
else with recent x86 kernels.
If a mapping is inside the (deliberately constrained) code segment then
it will appear to have X permission regardless of whether R or X was asked
for when it was mapped, so what we really need to do is allow the kernel
to add X to any mapping but not to take it away if we were expecting it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4985
normally give execute permission to memory allocated from the heap
with sbrk.
This also required fixing the smc1 test for amd64 to use mmap to
allocate memory so that it can have execute permission.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4983
was in the sigframe module has been moved into the coredump module
where it belongs and things fixed up to compiler again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4970
be part of a self-check. Instead, copy verbatim any IR preamble
preceding the first IMark. This stops cachegrind asserting on
self-checking translations.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4967
it can't even read the length of the block - just report an error as we
do if there isn't enough data for the rest of the block. Fix bug #114757.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4960
unique / 30000 total to 1000 unique / 100000 total. Programs are
generally bigger now than 3 years ago.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4957
go, but realistically we can't implement it portably, at least without
considerable performance overhead and some additional complexity.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4956
monster-sized programs better, increase the default freelist volume
from 1M to 5M. Maybe even that is too small.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4954
