Tom Hughes [Fri, 11 Nov 2005 08:39:34 +0000 (08:39 +0000)]
Suppress AT_SYSINFO in the auxiliary vector because it contains a
pointer to the system call routine in the sysinfo page and older
versions of glibc will use it. Fixex bug #115496.
Julian Seward [Thu, 10 Nov 2005 18:13:01 +0000 (18:13 +0000)]
Handle IR primops arising from running Altivec code. It seems Altivec
is stronger in the vector integer area than SSE, but weaker in the
vector FP area.
Tom Hughes [Thu, 10 Nov 2005 15:02:42 +0000 (15:02 +0000)]
Call VG_(unknown_SP_update) each time we switch to a new thread. This
ensures that current_stack is switched to the new thread's stack so
that we don't ignore the next stack update and hence fail to mark
memory that should be valid as valid.
Tom Hughes [Thu, 10 Nov 2005 14:24:08 +0000 (14:24 +0000)]
Add some extra debugging to the stack management module and simply
it a bit - there is no need to keep a full copy of the current stack
descriptor as we can just keep a pointer to it.
Julian Seward [Wed, 9 Nov 2005 14:43:03 +0000 (14:43 +0000)]
Third pass at the ppc32 ptrace stuff. It compiles now, but gcc complains that
the last two args to VG_(ptrace) are ints when they should be pointers. So
I'm still not sure whether this is right or not. Should I just put in a bunch
of casts to shut it up, or is it really expecting pointers and not ints?
Julian Seward [Tue, 8 Nov 2005 19:01:44 +0000 (19:01 +0000)]
Reinstate timestamping, sort-of, having trashed VG_(ctime) as part of
the glibc-removal process. Timestamps are now printed in terms of
elapsed wallclock time since startup, shown as days, hours, minutes,
seconds and milliseconds. The arithmetic is done with 32-bit unsigned
ints, so people doing Valgrind runs that last longer than 49.71 days
are going to see some funny results :-)
Tom Hughes [Tue, 8 Nov 2005 16:51:55 +0000 (16:51 +0000)]
Handle the PROT_GROWSDOWN and PROT_GROWSUP mprotect flags properly
which stops glibc falling over when a program requires an executable
stack and glibc has been built to assume that PROT_GROWSDOWN will work.
Tom Hughes [Mon, 7 Nov 2005 15:24:38 +0000 (15:24 +0000)]
Dual architecture support - this commit is a major rework of the build
system that allows multiple copies of valgrind to be built so that we
can build both x86 and amd64 versions of the tools on amd64 machines.
The launcher is then modified to look at the program being run and
decide which tool to use to run it.
Tom Hughes [Fri, 4 Nov 2005 16:46:19 +0000 (16:46 +0000)]
Allow rax/rbx/rcx/rdx (and their narrower counterparts) to be used
again but only after the high registers are exhausted or (and this is
the important point) if they are explicitly requested.
Also, don't use r8 as it confuses things as we can't tell an explicit
request from a generic request for a byte register.
Tom Hughes [Fri, 4 Nov 2005 15:36:05 +0000 (15:36 +0000)]
Fix the amd64 version of gen_insn_test.pl to strip any b/w/d suffix
from register names when generating the clobber list as gcc won't
recognise things like r8d but will recognise r8.
This allows us to use the high number integer registers for the tests
which is something Julian asked for ages ago.
Tom Hughes [Fri, 4 Nov 2005 11:31:33 +0000 (11:31 +0000)]
When unwinding the stack on x86/amd64 subtract one from the value of
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.
Tom Hughes [Wed, 2 Nov 2005 16:15:55 +0000 (16:15 +0000)]
Split faultstatus into the platform independent tests and those
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.
Tom Hughes [Wed, 2 Nov 2005 15:46:07 +0000 (15:46 +0000)]
The memcheck/tests/sigprocmask test is designed to test that we handle
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.
Tom Hughes [Wed, 2 Nov 2005 14:42:39 +0000 (14:42 +0000)]
The sloppyRXcheck logic in the sync checker was not correct - it was
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.
projects / thirdparty / valgrind.git / log
