* rename many functions to do with shadow memory handling, to
more clearly differentiate reads and writes directly of the
shadow state from client reads and writes, each of which
generate both a read and a write of the client state. It was
getting confusing (== hard to verify) in there.
* use idempotency of memory state machine transition rules to
speed up long sequential sections, speedups in range 0% to 28%
* remove 4-way Pord (EQ, LT, GT, UN) and associated machinery,
and replace it with something that merely computes LEQ in the
partial ordering, since that's all that is necessary, and
this simplifies some fast-case paths.
* add optional approx history mechanism a la DRD (start/end stack
of conflicting segment), much faster if you don't need exact
conflicting-access details
* libhb_so_recv: tick the VTS in the receiving thread; don't just
join with the VC in the SO. It's probably correct without this
modification, but that correctness is fragile and depends on
complex properties of how SOs are used/created. Much better to
be completely safe. (Needs cache-isation).
* get rid of unnecessary shadow memory state "SVal_NOACCESS"
and simplify associated fast-case paths in msmc{read,write}
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10589
This branch adds proper support for atomic instructions, proper in the
sense that the atomicity is preserved through the compilation
pipeline, and thus in the instrumented code.
These changes track the IR changes added by vex r1901. They primarily
update the instrumentation functions in all tools to handle the
changes, with the exception of exp-ptrcheck, which needs some further
work in order to be able to run threaded code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10392
sure the read-constraint <= the write-constraint. Failure to do this
leads to assertion failures later on. Fixes#181394.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10074
- When printing suppressions, never print more entries than there are in the
stack. This avoids bogus suppressions in some cases! (I haven't seen
them on Linux, but I have seen them on Darwin.)
- When getting a stack trace, stop if we get an IP of zero or one; that
means we've hit the end of the stack. And don't include that entry in the
stack trace, because it's a guaranteed "???" if it's ever printed which is
useless.
- In VG_(apply_StackTrace), we can now rely entirely on the n_ip parameter
rather than looking for 0 or -1, because that check is done when the stack
trace is first obtained. In other words, stack traces all use an n_ip
parameter to record their size, whereas previously they used an odd
mixture of n_ip and null-termination.
- Rename 'n_ips' variables as 'max_n_ips' where appropriate; those left as
'n_ips' truly describe how many IPs there are in the stack trace.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9793
.frames[1..N_FRAMES]. Instead store the hash in a separate .frames_hash
field, and the actual frames in .frames[0..N_FRAMES-1].
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@9778
* remove flags --trace-addr= and --trace-level=. These no longer
have any effect, so there's no point in having the associated flags.
* add flag --show-conflicts=no|yes [yes], which makes it possible to
disable the conflicting-access collection machinery. This makes
Helgrind run much faster. Perhaps useful in regression testing,
when it is desired only to find out if a race exists, but not to
collect enough information to easily diagnose it.
* add flag --conflict-cache-size= [1000000], which makes it possible
to control how much memory is used for storage of information about
historical (potentially-conflicting) accesses.
* Update comments on the conflicting-access machinery to more closely
reflect the code. Includes comments on the important aspects of
the value N_OLDREF_ACCS. Increase said constant from 3 to 5.
* Fix bug in event_map_bind: when searching for an OldRef.accs[]
entry that matches the current access, don't forget to also
compare the access sizes. The old code only compared the thread
identity and the read/writeness.
* hg_main.c: disable Dwarf3 variable/type info reading by default.
Mostly this provides little benefit and can cause Helgrind to use
a lot more time and memory at startup.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8845
in the case where VG_(clo_backtrace_size) < N_FRAMES (that is, with
--num-callers=N where N < N_FRAMES).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8820
find conflicting accesses that overlap the current access in any way,
rather than just match at the addresses. This allows reporting of
conflicts between accesses which overlap but are not the same
size/alignment.
Doesn't seem to always work reliably, for reasons I don't understand,
but I so far failed to make a small test case.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8811
read-or-writeness of each access, so that these can be displayed in
error messages.
* Use recorded read-or-writeness info to avoid producing error
messages that claim claim two reads race against each other -- this
is clearly silly. For each pair of racing accesses now reported, at
least one of them will (should!) always now be a write, and (as
previously ensured) they will be from different threads.
* Lookups in the conflicting-access map is expensive, so don't do that
as soon as a race is detected. Instead wait until the update_extra
method is called.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8809
(primary) mapping of the conflicting-access mechanism. This speeds
up Helgrind by 0% to 30% depending on the workload.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8807
machinery, so as to allocate fewer chunks of memory. This increases
the speed of Helgrind by about 10% on some apps, which probably means
the conflicting-access machinery itself is about 20% faster.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8803
(counts) of generation numbers in the oldrefTree, instead of using a
WordFM as an associative array. This significantly accelerates the
event map garbage collector.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8794
instead of the more aggressive setting, which appeared to cause a
large number of extra race reports.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8793
in a (C)onstraint state. The former approach can cause races to be
missed. Also, update state machine slightly following re-analysis
thereof.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8788
asserted on: if all the entries in the event map are in the same
generation, then we have no LRU information at all with which to
decide which entries to discard. So in this case throw away half of
them randomly -- there's nothing better we can do.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8783
* get rid of 'struct _EC' (a.k.a 'struct EC_') and use ExeContext
everywhere
* remove stacktrace_to_EC and call
VG_(make_ExeContext_from_StackTrace) directly
* comment out some unused code
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8749
minor changes to make stack unwinding on amd64-linux approximately
twice as fast as it was before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@8707
