Fixed the inline assembly code such that it also works correctly with gcc 4.4.0. While accessing stack variables from inline assembly code that modifies the stack pointer works fine with gcc 3.0 - gcc 4.3 with optimization disabled, it gives incorrect results with gcc 4.4.0.
Merge coregrind/ changes from branches/MESSAGING_TIDYUP r10464.
This commit tidies up and rationalises what could be called the
"messaging" system -- that part of V to do with presenting output to
the user. In particular it brings significant improvements to XML
output.
Changes are:
* XML and normal text output now have separate file descriptors,
which solves longstanding problems for XML consumers caused by
the XML output getting polluted by unexpected non-XML output.
* This also means that we no longer have to hardwire all manner
of output settings (verbosity, etc) when XML is requested.
* The XML output format has been revised, cleaned up, and made
more suitable for use by error detecting tools in general
(various Memcheck-specific features have been removed). XML
output is enabled for Ptrcheck and Helgrind, and Memcheck is
updated to the new format.
* One side effect is that the behaviour of VG_(message) has been
made to be consistent with printf: it no longer automatically
adds a newline at the end of the output. This means multiple
calls to it can be used to build up a single line message; or a
single call can write a multi-line message. The ==pid==
preamble is automatically inserted at each newline.
* VG_(message)(Vg_UserMsg, ..args..) now has the abbreviated form
VG_(UMSG)(..args..); ditto VG_(DMSG) for Vg_DebugMsg and
VG_(EMSG) for Vg_DebugExtraMsg. A couple of other useful
printf derivatives have been added to pub_tool_libcprint.h,
most particularly VG_(vcbprintf).
* There's a small change in the core-tool interface to do with
error handling: VG_(needs_tool_errors) has a new method
void (*before_pp_Error)(Error* err) which, if non-NULL, is
called just before void (*pp_Error)(Error* err). This is to
give tools the chance to look at errors before any part of them
is printed, so they can print any XML preamble they like.
* coregrind/m_errormgr.c has been overhauled and cleaned up, and
is a bit simpler and more commented. In particular pp_Error
and VG_(maybe_record_error) are significantly changed.
The diff is huge, but mostly very boring. Most of the changes
are of the form
- VG_(message)(Vg_UserMsg, "this is a message %d", n);
+ VG_(message)(Vg_UserMsg, "this is a message %d\n", n);
Unfortunately as a result of this, it touches a large number
of source files.
Ignore MALLOCLIKE_BLOCK/FREELIKE_BLOCK if addr==0. Fixes bug 137073. DRD
now has its own copy of custom_alloc.c which is a little different to
Memcheck's; making them both work with the same version was too difficult.
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.
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.
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.
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.
projects / thirdparty / valgrind.git / log
