VG_(record_startup_wd) which records the working directory at startup,
and VG_(get_startup_wd) which later tells you what value was recorded.
This works because all uses of VG_(getcwd) serve only to record the
directory at process start anyway. The motivation is that AIX does
not support sys_getcwd directly, so it's easier for the launcher to
ship in the required value using an environment variable. On Linux
sys_getcwd is used as before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6764
This hopefully makes the whole issue with cycles easier to understand.
And no, this does not get rid of the description of cycles, carefully
crafted by Julian ;-)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6747
* Looks a little bit more like the Cachegrind manual
(at least in front)
* Removed the out-of-place general section about profiling
and gprof. Perhaps something like this can be put at
another place
* Notes about Callgrinds problems with call tracing on PPC
* Include usage of callgrind_annotate, and note its lack of
cycle detection
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6734
- extend some to 2007
- use njn@valgrind.org instead of njn25@cam.ac.uk
- use "tool" instead of "skin"
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6703
This introduces some macros to shorten the code for output of
strings to a file descriptor. I could use this a lot,
but this commit limits itself to the potential buffer overruns
(to ease backporting - provided we want to do this)
Heavy use of the macros probably blows up the code. Perhaps
it would be better to provide e.g. a VG_(write_str3) function
in the tool API.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6618
After the change in r6413, CLG_(run_thread) is called a
lot more often, increasing the polling overhead to check
for a callgrind command file (created by callgrind_control
for controlling a callgrind run in an interactive way).
This reduces the calls to only be done every 5000 BBs,
which gives a similar polling frequency as before.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6414
- Rename the event to 'thread_runstate'.
- Add arguments: pass also a boolean indicating whether the thread
is running or stopping, and a 64-bit int showing how many blocks
overall have run, so tools can make a rough estimate of workload.
The boolean allows tools to see threads starting and stopping.
Prior to this, de-schedule events were invisible to tools.
- Call the callback (hand the event to tools) just before client
code is run, and again immediately after it stops running. This
should give correct sequencing w.r.t posting of thread creation/
destruction events.
In order to make callgrind work without complex changes, I added a
simple impedance-matching function 'clg_thread_runstate_callback'
which hands thread-run events onwards to CLG_(thread_run).
Use this new 'thread_runstate' with care: it will be called before
and after every translation, which means it will be called ~500k
times in a startup of firefox. So the callback needs to be fast.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6413
in r6365 for cachegrind.
This needs 3 fixes (the 4th is ifdef'd out) for the
3 versions of the simulator in callgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6367
Makefile.am changes for AIX5. Almost all boilerplate stuff fitting in
with the existing factorisation scheme. The only change of interest
is that configure.in now generates automake symbols of name
VGP_platform and VGO_os, whereas previously it just made VG_platform
which was a bit inconsistent with the VGP/VGO/VGA scheme used in C
code.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6242
interface, except for the syscall numbers, into that. Mostly this
means moving include/vki-*.h to include/vki/vki-*.h.
include/pub_tool_basics.h previously dragged in the entire kernel
interface. I've done away with that, so that modules which need to
see the kernel interface now have to include pub_{core,tool}_vki.h
explicitly. This is why there are many modified .c files -- they have
all acquired an extra #include line.
This certainly breaks all platforms except x86. Will fix shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6225
This fixes bug 134316: when an program in callgrind does
a fork, callgrind_control does show both now, and they
can be controlled separately.
However, missing in this patch is zeroing of cost centers
directly after the clone syscall in the child.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6082
This callgrind option produces lines starting e.g. with
"jfi" in the profile data files, which specifies a
source file change between a jump source and jump target.
This itself is meaningless for callgrind_annotate, as
it can not show jump information in its annotation.
However, such "jfi" lines can contain important mapping
info for a (file ID, file name) tuple - which leads to
further warnings and problems if ignored.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6064
This checks all of callgrinds client requests,
and accordings actions (zero/dump) in different states
(collection on/off, instrumentation on/off).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6058
This bug shows up when callgrind dumps data of a BB with 0 instructions
(the segfault only appears on x86_64; for x86 we were "lucky").
"BB with 0 instructions" happens when you switch on instrumentation
(and callgrinds call graph tracing starts with an emtpy shadow call
stack) in the middle of a run: Whenever the shadow callstack
is empty, but callgrind sees a return instruction (ie. a shadow
callstack underrun), it creates an artifical BB which is faked to
have called the function we are returning from.
This way, the call arc is noted and will appear in the dump.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6053
When instrumentation mode is switched off, we want to fully
reset callgrinds internal execution state, which includes
the shadow call stack and function stack for context generation.
The latter was not completely reset before.
The bug showed up when switching the instrumentation mode on for
the second time, leading to
Callgrind: callstack.c:211 (vgCallgrind_push_call_stack):
Assertion 'current_entry->cxt != 0' failed.
This commit also improves debug output a little bit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6045
I just noticed that this is still a little wrong, as counts for e.g.
"strcmp" from libc and "strcmp" from ld.so will make up only one entry,
with the object name randomly choosen... but otherwise, it matches
with the data shown by KCachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6044
Bug description: Very similar to cachegrind, callgrind stores
metainformation per guest instruction; this meta information is
given when calling into the simulator. In contrast to cachegrind,
callgrind keeps this info when the source is discarded, and checks
on retranslation whether the same meta info is generated.
This check sometimes fails: E.g. for rep x86 instructions, 2 simulator
calls
are usually generated for one x86 instruction (the instruction fetch and
a
data access), thus overwriting the data_size meta information for one
x86
instruction first with 0, and afterwards e.g. with 1. The check on
retranslation
fails because of this. The fix is to only write/check data_size values
>0.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5942
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
