This adds an option to change the default handling of jumps
between functions. Usually, a jump between functions is
interpreted as call, because such jumps are typically
generated by compilers on tail recursion optimization, and
we want to present this as call to the user. Thus, such
a jump pushes a call onto callgrinds shadow stack.
The option "--pop-on-jump" changes this to pop+push the
shadow callstack: then, a jump between functions is seen
as a return to the caller and a new call.
The default behaviour is _bad_ for using callgrind with
self-hosting. Valgrinds inner loop VG_(run_innerloop)
jumps to generated code, and this code jumps back to
the inner loop. Thus, every executed BB adds 2 calls
to an ever increasing shadow call stack, leading to
memory consumption increasing with runtime :-(
So: For self-hosting valgrind with an outer callgrind,
always use option "--pop-on-jump" for the outer callgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5869
the --base option, which allows to specify another
directory for dumps and control/result files.
With "--base=/tmp/foo", we want control/result files
in "/tmp", and not in a directory "/tmp/foo/".
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5862
- callgrind_control was not working, because it checks the
"command syntax version" to be at most 1 before doing anything.
But callgrind used Valgrinds version for this (3.2.0). Now we
define a separate version COMMAND_VERSION for the syntax format
of control and result files.
Strictly, such a version is not needed for interaction of
callgrind and the script callgrind_control itself, as they are
delivered in the same package. But there are also external
controlling tools (most notable KCachegrind)
- Some systems make it difficult for callgrind_control to
automatically detect running callgrind processes. To make
interactivity work, one has to provide the cwd with -w.
For commands expecting a result from callgrind, this result
was delivered in the wrong result file.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5861
The simwork tests check different cache simulator
options/modes. These tests should be extended to
check for the produced call graph.
The threads check tests the callgrind mode where
counts are aggregated separate per thread.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5816
run a custom client request.
By doing this, I found out that callgrind.h still defined
client requests for VG 2 :-( Obviously, nobody was using
them. This is fixed, and other small things to make the
test run, too.
Notice for myself: regression tests are needed.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5807
