- Moved all the insn_* tests into x86/ subdirectories. What are the chances of
me getting this right on the first attempt?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2809
- Change regtest script to print a message if a test is skipped due to the cpu
being of the wrong type.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2803
- Rewrote tests/cputest.c so that it can apply to different kinds of
processors. The idea being that any arch-specific tests have a cpu_test:
label in their .vgtest file, so they'll only get executed if the right
machine is being used.
- Rewrote a bunch of .vgtest files accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2802
- Factored out the remaining arch-specific code from vg_libpthread.c.
- Also fixed up the build process for x86/libpthread.c, which was done
wrongly in the previous commit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2798
safer kernel interface to signalling a particular thread and it ensures
you can only send a signal to one of your own threads.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2795
architectures. Had to recast it as valgrind.h.in; now at configure time the
appropriate #define is set so that the appropriate snippet of assembly code is
chosen. It's done this way rather than with x86/ etc. directories like the
rest of Valgrind, because this header file must stand alone for inclusion by
other programs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2794
- factor out the setting of syscall results, which can be more complicated
than just putting a value in the result register (eg. PPC has to fiddle with
multiple registers).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2789
of using an assembly hack to find the stack pointer at startup, we find it from
argv. It's much simpler, avoids linking games, is platform independent, and
works on PPC.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2782
condition variable. The pthread routines now use a timeout of 0xfffffffe
if the user asks for something longer than that otherwise we will wrap
around and actually get a much shorter timeout.
The scheduler has also been changed so that it it now limits itself to
a timeout of 0x7fffffff when working how how long to poll for. This won't
affect how long a thread actually sleeps for as we'll just wind up waiting
a bit more on the next pass round the loop.
This fixes bug 76845.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2781
thread was waiting on has been unlocked while the signal handler was
running and resume the thread if it was.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2779
delivered that the thread state is temporarily changed from WaitMX or WaitCV
to Running while the signal handler is running. The original state is then
restored when the handler returns.
This patch forces the associated_mx and associated_cv values to be cleared
at the same time and the original values restored afterwards. Without this
the scheduler state will not be considered sane while the handler is running.
This is based on a patch from Kenneth Schalk and fixes a problem he had
with posting to a semaphore in a signal handler. It also allows a couple
of assertions in the scheduler sanity check to be uncommented.
BUG: 72082
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2778
in a similar way to the previous patch that removed the limit on the
number of semaphores and fixes bug 86264.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2776
that doesn't route signals to the correct threads properly) the siginfo
data was not being propagated to any signal handlers installed by the
client program.
This is because the main thread routes the signal to the proxy LWP by
using the tkill system call but that then appears in the proxy as a user
initiated signal and the original siginfo data is lost.
This patch adds a small queue of siginfo data for pending sigals to
each thread's state so that when the proxy LWP passes the signal back
to the main thread the relevant siginfo data can be recovered and passed
on to any signal handlers. Thix fixes bug 91325.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2773
It appears that the resolution of the address is to forward to is now
working properly but that on some systems the second part of the assertion
fails because the dynamic linker resolves the name of the function being
forwarded to the glibc version rather than the version in valgrind's pthread
library.
The solution is to use dlopen to explicitly obtain a handle to valgrind's
pthread library and then lookup the symbol with dlsym when doing the
comparison in the assertion.
BUG: 88614
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2772
been changed to return the ID of the thread group leader but which do not
have a gettid system call.
This breaks VG_(gettid) which assumes that the getpid system call will
give the thread ID if the gettid system call does not exist.
The (horrible) solution is to use readlink to see where /proc/self points
when the gettid system call fails.
BUG: 82114
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2771