This obviously was already wrong in 3.2.x :-(
* Old --fn-recursion=... / --fn-caller=... options are called
--separate-recs=... / --separate-callers=... since quite some
time for consistency with e.g. --separate-threads=yes.
Error noted from bug 153335.
* Function specifications support wildcards since quite some time;
specification of a prefix only does not work, but the full
function has to match. This was needed to allow to specify 'foo'
without also specifying 'foo1'.
* The script 'callgrind' does not exist since merging into
valgrind.
* Rename callgrind from being a 'heavyweight' to a 'call graph'
profiler, similar to the description in the quick start overview.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7272
In dump.c, gcc complains that 'param max-stack-frame-growth' would be
exceeded, so remove 'inline' spec.
All other warnings are of the form 'call is unlikely and code size
would grow'. These aren't interesting. Remove -Winline.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7164
callgrind_control uses files /tmp/callgrind.info.* to be able to
locate running callgrind processes. These files can be read only by
the user which started callgrind. The callgrind_control script
did not check for "permission denied" on opening these files, which
resulted in some unexpected errors. Now, it is checked whether
the "open" was successful, and if not, we skip the according callgrind
process.
Fixes bug 149963.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6861
Prepend the file name of a source file with the directory
if that is available. This not only gets rid of problems with the
same file name used in different paths of a project, but lets
the annotation work out of the box without having to specify any
source directory.
Works both with callgrind_annotate and KCachegrind without any
changes there.
Inspired by Nick's change to cachegrind doing the same thing
in r6839 (and gets rid of a FIXME in the source)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@6850
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
