[Valgrind-developers] patch-o-rama

[Jeremy F. <je...@go...>]

New patches (not counting 20-24 which I've posted about before):

25-hg-free-mutex
    HELGRIND: Track memory frees and allocates, looking for the freeing
of locked mutexes. Also makes some prime hash sizes actually prime.


26-hg-client-reqs
    HELGRIND: first client requests. Adds a request to return memory to
its virginal state (useful for allocators which recycle memory), and one
to put memory into an error state (useful for suppressing errors from
known races).


27-nvalgrind
    Make valgrind.h pay attention to the preprocessor symbol NVALGRIND.
If defined, it compiles out the Valgrind magic sequence and just assigns
the result with the default return. This is analogous to NDEBUG's effect
on assert().


28-sigtrap
    Trap signals which the client program has left with the default
action and who's default action is to dump core, and print a stack
backtrace on exiting if they happen.


29-hg-rename-hg_mutex_t
    HELGRIND: rename hg_mutex_t, because it was annoying me.


30-hg-clo
    HELGRIND: command line option processing infrastructure (nothing
using it yet)


31-hg-shadow-execontext
    HELGRIND: Add option to record ExeContext for every word access.
This is probably very slow and memory hungry, but it helps make the
error reports more useful. Defaults to off.


32-hg-lifetime-segments
    HELGRIND: implement the algorithm described in "Runtime Checking of
Multithreaded Applications with Visual Threads". Rather than working
with thread IDs, this algorithm breaks the lifetime of a thread up into
thread lifetime segments, and arranges them in an interference graph.

    If a memory location is in exclusive state and it is touched by
another thread, it compares the TLSs of the old owner and the new
thread. If the two TLSs can't possibly overlap in time (for example, one
TLS is the parent before a child thread is created, and the other TLS is
the child thread) the memory location's ownership is transferred rather
than moving it into a shared state. This allows a parent thread to set
up some memory and then create a new child, handing ownership of that
memory to the child, without generating spurious errors.

    At present the only synchonization events used to create new TLSs
are thread create and thread join, though in principle any
synchronization event would work.


33-pre_mutex_lock
    HELGRIND: two updates: add a pre_mutex_lock tracking function, so
the skin can do something before the thread blocks. This allows us to do
lock ordering tests before the thread blocks in the deadlock we'd like
to report...


36-hg-optim
    HELGRIND: various microoptimizations and small tidyups.


37-hg-private-stack
    HELGRIND: by default, assume that thread stacks are thread-local.
This means that they are always initalized to be exclusively owned by
their thread (rather than virgin), and no access checks are generated
for stack-relative memory references (ie, relative off ESP or EBP). This
saves about 70% (statically) of checks on memory accesses.

    This is enabled by default, but can be disabled with
--private-stacks=no


38-hg-lazy-lasttouch
    HELGRIND: rather than recording the last access, record the last
state change. This is more interesting and useful, and uses up a lot
less memory when using (now inaccurately named) --show-last-access=all.


39-lock-prefix
    Add a new UInstr LOCK to represent a "lock" prefix in the
instruction stream. This has the same semantics as NOP, but allows a
skin to tell whether a group of UInstrs associated with an x86
instruction are meant to be locked.

    HELGRIND: uses the LOCK UInstr to automatically take and release a
special __BUS_HARDWARE_LOCK__ around locked instructions. This only
works properly if all instructions touching a given address are locked
(even reads).