Track vex r1907 (introduce Iop_CmpCas{EQ,NE}{8,16,32,64} and use them
for CAS-success? tests).
Detailed background and rationale in memcheck/mc_translate, comment
"COMMENT_ON_CasCmpEQ".
This commit changes the Memcheck instrumentation of IRCAS so as not to
do a definedness check on the success/failure indication. Also, by
being able to identify via the Iop_CasCmpEQ primitives any such checks
independently created by front ends, it can avoid instrumenting these
too.
All this is to avoid reporting new false positives observed on Fedora 7
(x86?) and openSUSE 10.2 (x86) following the recent merge of branches/DCAS.
Add new integer comparison primitives Iop_CasCmp{EQ,NE}{8,16,32,64},
which are semantically identical to Iop_Cmp{EQ,NE}{8,16,32,64}. Use
these new primitives instead of the normal ones, in the tests
following IR-level compare-and-swap operations, which establish
whether or not the CAS succeeded. This is all for Memcheck's benefit,
as it really needs to be able to identify which comparisons are
CAS-success tests and which aren't. This is all described in great
detail in memcheck/mc_translate.c in the comment
"COMMENT_ON_CasCmpEQ".
Modified recursive_mutex regression test: improved portability by removing usage of alarm() / all output is now sent to stderr / full output is now compared instead of only a summary.
Added a suppression pattern for call stacks referencing the function _Unwind_ForcedUnwind / generalized the suppression pattern for the function _Unwind_ForcedUnwind_Phase2.
Add support for IRStmt_CAS to the h_ instrumenter. This should stop
exp-ptrcheck asserting on threaded programs on x86 and amd64. Vast
amounts of fiddly complication that makes my head hurt. Urr.
Liberalise IRTemp bookkeeping in the h_ instrumenter, so as to allow
addition of non-shadow IRTemps without causing it to collapse into
assertion failures. This changes is a simplified version of what was
committed in
svn://svn.valgrind.org/valgrind/branches/DCAS/memcheck/mc_translate.c
r10109.
Flatten out the directory structure in the priv/ side, by pulling all
files into priv/ and giving them unique names. This makes it easier
to use automake to build all this stuff in Valgrind. It also tidies
up a directory structure which had become a bit pointlessly complex.
Fix handling of multiple signal deliveries in a row
This fixes bug 136154.
Background:
The function stack - CLG_(current_fn_stack) - is a stack of
pointers to the fn_node structs of the currently active
functions. This stack is used for determining current context
from call chain to current function, and modified on entering
(via push_cxt) and leaving a function.
Entering a signal handler will push a 0 to the function stack
to make the context only dependend on the call chain inside of
the signal handler.
Thus, delivering two signals in a row should push two times a
0 value onto the function stack. However, the second 0-push was
incorrectly suppressed, leading to a failed assertion when
returning from the 2nd signal handler.
This also fixes a bug with incorrectly zeroing global cost
counters when changing the execution context, introduced with
r10386.
Tom Hughes [Wed, 1 Jul 2009 11:59:20 +0000 (11:59 +0000)]
When looking for the text section in a PE executable ignore any
code section which is marked as uninitialised.
This can happen if you have incremental linking enabled in Visual
Studio, which causes a .textbss section to be added before the real
text section. We were picking up that .textbss section and using it to
compute the avma and bias for the code which was giving completely the
wrong results.
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.
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.
The change adds a new IR statement kind, IRStmt_CAS, which represents
single- and doubleword compare-and-swap. This is used as the basis
for the translation of all LOCK-prefixed instructions on x86 and
amd64.
The change also extends IRExpr_Load and IRStmt_Store so that
load-linked and store-conditional operations can be represented. This
facilitates correct translation of l[wd]arx and st[wd]cx. on ppc in
the sense that these instructions will now eventually be regenerated
at the end of the compilation pipeline.
Add some more functions to the default --alloc-fns list. Had to tweak how
verbose output is printed so that the tests would be ok, now that different
platforms have different alloc-fns lists.
Fix statistics with multiple changes of instrumentation state
This fixeds bug 150606.
When switching on instrumentation, the current function got the
wrong (too large) inclusive cost when instrumentation ever was on before.
The reason was that the global (ever increasing) event counters where
not reset on toggling instrumentation state. The global counters
are used to calculate inclusive cost of a function by getting the
difference of the global counters at leaving minus their value at
enter time. When leaving a function which was not encountered
to be entered before (a stack underrun of the shadow stack), it is
assumed that this function was entered with instrumentation switched
off. Then, the absolute value of global counters is used to calculate
the inclusive cost. Thus, these global counters have to be zeroed
at instrumentation change to allow for senseable inclusive costs
of functions which were not observed to be entered.
Make the Linux launcher more like the Darwin one in how it reads the
executable headers. This means it no longer crashes on an empty executable.
Fixes bug 156065.
Bart Van Assche [Wed, 24 Jun 2009 18:35:02 +0000 (18:35 +0000)]
Use the value set in the environment variable DRD_SEGMENT_MERGING_INTERVAL if the segment merging interval has not been specified as a command-line option.
This commit merges the BUILD_TWEAKS branch onto the trunk. It has the
following improvements:
- Arch/OS/platform-specific files are now included/excluded via the
preprocessor, rather than via the build system. This is more consistent
(we use the pre-processor for small arch/OS/platform-specific chunks
within files) and makes the build system much simpler, as the sources for
all programs are the same on all platforms.
- Vast amounts of cut+paste Makefile.am code has been factored out. If a
new platform is implemented, you need to add 11 extra Makefile.am lines.
Previously it was over 100 lines.
- Vex has been autotoolised. Dependency checking now works in Vex (no more
incomplete builds). Parallel builds now also work. --with-vex no longer
works; it's little use and a pain to support. VEX/Makefile is still in
the Vex repository and gets overwritten at configure-time; it should
probably be renamed Makefile-gcc to avoid possible problems, such as
accidentally committing a generated Makefile. There's a bunch of hacky
copying to deal with the fact that autotools don't handle same-named files
in different directories. Julian plans to rename the files to avoid this
problem.
- Various small Makefile.am things have been made more standard automake
style, eg. the use of pkginclude/pkglib prefixes instead of rolling our
own.
- The existing five top-level Makefile.am include files have been
consolidated into three.
- Most Makefile.am files now are structured more clearly, with comment
headers separating sections, declarations relating to the same things next
to each other, better spacing and layout, etc.
- Removed the unused exp-ptrcheck/tests/x86 directory.
- Renamed some XML files.
- Factored out some duplicated dSYM handling code.
- Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting
Makefile.am files to be much more standard.
- Cleaned up m_coredump by merging a bunch of files that had been
overzealously separated.
The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude
the added Makefile.vex.am, or 997 once the hacky file copying for Vex is
removed. And the build system is much simpler.
Bart Van Assche [Sun, 21 Jun 2009 18:07:35 +0000 (18:07 +0000)]
Combined DRD_(thread_new_segment)() and DRD_(thread_combine_vc_sync)()
into the function DRD_(thread_new_segment_and_combine_vc)() because
before DRD_(thread_combine_vc_sync)() was called the function
DRD_(thread_new_segment)() was always called.
Callgrind: fix instrumentation for arbitrary events per guest instruction
(should fix bug 169505)
This uses the same event queue scheme as cachegrind and lackey, and
same kind of helpers (1/2/3 Ir events, Ir+Dr, Dr, Ir+Dw, Dw).
Note that in contrast to Cachegrind, Callgrind interpretes a modify event
as Dw (otherwise the cache model generating write back events would not work).
Callgrind uses per-(guest)instruction event sets for cost counters.
An per-instruction eventset is incrementally extended as events for the
same guest instruction are flushed. Event sets always start with Ir counters,
but depending on Dr/Dw order afterwards, there exist IrDr(Dw) and IrDw(Dr).
Per-instruction event sets now are consistently named according to event ordering.
Event set "sim" is a subset of "full", was never used and was removed.
projects / thirdparty / valgrind.git / log
