by the scheduler, not by generated code. So pass in the relevant
ThreadState*; don't get it from VG_(get_current_tid)().
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@101
Fall back to a compromise position, which makes my mutex implementation
initialiser- and structure-compatible with LinuxThreads, and ditto the
upcoming condition var implementation. In particular this means that
((ThreadId)0) is an invalid thread ID, so vg_threads[0] is never used,
and vg_threads[1] specially denotes the "main" thread.
Remove the scheme of having a linked list of threads waiting on
each mutex. It is too difficult to get the right semantics for
when a signal is delivered to a thread blocked in pthread_mutex_lock().
Instead, use the old scheme of each thread stating with its .waited_on_mx
field, which mutex it is waiting for. This makes pthread_mutex_unlock()
less efficient, but at least it all works.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@100
for implementation of condition variables.
* Use the native pthread_mutex_t directly; we no longer have our own
VgMutex type nor a fixed array of them.
* Give ThreadState a new field q_next :: ThreadId, used to make a
linked list of threads waiting on a mutex, or condition variable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@99
Various enhancements:
* Make the error message system more thread-aware.
* Fix stupid bug in do_pthread_create causing incorrect initial
%ESP values sometimes.
* Fix various other minor things needed to make opera work.
Performance of threaded apps is pretty terrible. This needs
looking into.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@98
VG_(unimplemented). In future this will not be enabled by default due
to the danger of recursion of assertion failures.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@92
of pthread event tracing. And allow this info to be passed across to
the client, where vg_libpthread.c uses it to also control verbosity.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@91
on the client-request subsystem, and disabling it is no longer a
sensible thing to do.
Also: in the manual, mention flags --trace-sched= and --trace-pthread=.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@79
Turns out these insns are also available as Grp8 extensions, with
literal bit-offset values. Nuisance. I've #if 0'd out the old code
which implements them since am too lazy to fix them properly, and I
can't find any cases of their use anyway. I'll wait until someone
yelps.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@75
request to shutdown valgrind are done with the client request
mechanism too. This is much better than having to check all
call/return addresses.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@57
for pthread_* support. Major changes:
* Valgrind now contains a (skeletal!) user-space pthreads
implementation. The exciting bits are in new file vg_scheduler.c.
This contains thread management and scheduling, including nasty crud
to do with making some syscalls (read,write,nanosleep) nonblocking.
Also implementation of pthread_ functions: create join
mutex_{create,destroy,lock,unlock} and cancel.
* As a side effect of the above, major improvements to signal handling
and to the client-request machinery. This is now used to intercept
malloc/free etc too; the hacky way this is done before is gone.
Another side effect is that vg_dispatch.S is greatly simplified.
Also, the horrible hacks to do with delivering signals to threads
blocked in syscalls are gone, since the new mechanisms cover this case
easily.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@52
--check-addrVs=no. The default behaviour, =yes, is the original
behaviour. So far this is undocumented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@32
UInstrs accordingly. Fixes a bug in the simulated CPU in which the
results of f{u}comi{p} FPU insns were ignored, potentially leading to
wrong program behaviour. This will only have happened to people using
P6/P7/K7 class CPUs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@30
