On some MIPS platforms, we had an issue in which SC would fail each time
due to some memory access occuring in the RMW region.
If code for simulator events is called before LL, it can help SC to pass.
This change fixes a few LL/SC issues on MIPS arch.
The patch by Josef Weidendorfer.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13136
Option sp-at-mem-access can be used by tools which do not
need an up to date BP and IP at each mem access.
It is needed however to have SP up to date at each memory
access, as an up to date SP is needed to grow the stack in
m_signals.c
Tools massif, cachegrind and callgrind are using sp-at-mem-access
as default.
None tool could also use sp-at-mem-access but default is kept
to unwindregs-at-mem-access (similar to memcheck, drd, helgrind, exp-sgcheck).
exp-dhat, exp-bbv, lackey have not been looked at to see if they
could make use of sp-at-mem-access.
Validated on x86, amd64, ppc64 and s390x.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12872
To detect calls and returns, Callgrind's heuristic
starts with using the jumpkind got from VEX for
a control flow change instruction. However, for
side exits, it always assumed a (conditional) jump,
which holds true for x86, but e.g. not for ARM.
This fixes Callgrind to use the jumpkind found
by VEX for all exits, which should help making
Callgrind work for ARM. It also moves the check
whether a boring jump is actually a fall-through
to instrumentation time. This changes (fixes) the
result for indirect jumps to the next instruction,
which should not be classified as fall-through
(anyway, this case is probably very rare).
This patch introduces an own enum for jump kinds
in Callgrind. This is less confusing than misusing
the VEX jump kind type, as Callgrinds wants
to distinguish BB fall-throughs from real jumps
(which both are Ijk_Boring in VEX).
Also, setup_bbcc now stores separately whether the
jump kind is conditional or not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12269
This is the last part of moving from command file polling
to the vgdb ptrace method for interactive control of Callgrind.
VG 3.7.x ported callgrind_control to vgdb (in r11867), but
still did command file polling to support existing KCachegrind
releases. KCachegrind from upcoming KDE SC 4.8 will use
callgrind_control instead of manually writing command files.
The main benefit from this is, apart from getting rid of
continous file polling activity in Callgrind, that blocked
processes can now respond to callgrind_control.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12268
fields. This makes the --ct-verbose=1 output make a lot more sense
for Thumb code. Should have no effect on any other platform.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12260
The vgdb "status" monitor command is still available, but
used for pretty printing of status information now (acutally,
just some place holder for real information up to now: just
number of running threads). The internal interface used by
callgrind_control to provide stack traces and event counts
is using "status internal", and is not documented, as the
format is not for human consumption.
This also adds some documentation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12014
To support different instrumentation modes, callgrind calls
VG_(discard_translations), which up to now does not belong to the
functions allowed to call from tools, as this is unsafe if
called from generated code.
Callgrind hacks around that by defining the prototype itself.
However, in r4789 (from Sep 27 2005!) a 3rd arg was added for
debugging output. Thus, callgrind could crash if called
with "-d -d".
As the "instrumentation off" feature seems to be used quite often,
it really would be nice to have VG_(discard_translations) callable
from tools...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11906
--cmd-time-out
* changed prefixes of Valgrind core monitor commands from vg. to v.
* removed prefixes of Tool monitor commands
* memcheck leak_check 'leakpossible' arg renamed to 'possibleleak'
* memcheck make_memory 'ifaddressabledefined' arg renamed to
'Definedifaddressable'
(with uppercase D to avoid confusion with 'defined' arg).
* vgdb options
- Some doc updates : more logical option order documentation,
specify 'standalone' for options aimed at standalone usage.
- added option --cmd-time-out for standalone vgdb
(comment of Josef Weindendorfer, needed to interface with a callgrind GUI)
* updated tests according to the above.
* updated documentation according to the above.
* some additional minor doc fixes/clarifications
(Philippe Waroquiers, philippe.waroquiers@skynet.be). Bug 214909
comment 111.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11844
Calls via function pointers are indirect branches, and thus
should call into the indirect branch predictor simulation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11212
Callgrind now uses Cachegrind's command line option to switch
on simulation: "--branch-sim=yes/no" for branch prediction,
and "--cache-sim=yes/no" for cache simulation (for more
consistency and to avoid confusion). However, the previously
used "--simulate-cache=yes/no" still is supported but deprecated.
Included: according documentation and tests.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11207
To count global bus lock events, use "--collect-bus=yes".
For x86, this will count the number of executed instructions
with a lock prefix; for architectures with LL/SC, this will
count the number of executed SC instructions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11167
Offsets of groups within event sets are now
stored in a offset table as part of the event set, and
can be accessed directly. Before, offsets were hardcoded
all over the place. This should make addition of further
event groups much simpler.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11165
The global cost counters, which are used for printing the
summary line, where zeroed before in init_exec_state(), called
by unwind_thread().
Stack unwinding (i.e. unwind_thread) is also done at instrumentation
state changes, and there, we want the cost counters to be zeroed
(was fix for bug 150606). Do this explicitly now.
PS: The correct fix for bug 150606 is not to zero the cost counters
(we do not really want this at instrumentation state changes), but
to store the current counter values in a "last_instr_state_on_cost"
counter, and use this as the global cost counter on enter for functions
which are left but were not detected to be entered.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10782
* For all tools and the core, don't show statistics when -v is in
effect. Instead, try to restrict -v to mostly user-useful
stuff.
* A new flag --stats=no|yes [no] produces statistics output instead.
* Fix longstanding problem in that Memcheck's leak checker ran after
the core's error manager module shut down, thereby not showing use
counts of leak suppressions. This fixes#186790.
* As a consequence, the leak checker text output of Memcheck has
changed a bit -- leak check is done before the final error
summary is done (much more logical), and the output has been
tidied up a bit.
* Helgrind, Drd and Ptrcheck now also print "For counts of
detected and suppressed errors, rerun with: -v", which makes
them consistent with Memcheck in this regard. These are
filtered out by the regtest filter scripts.
For all tools except Memcheck, the regtests are unchanged. On
Memcheck regtests still fail due to rearrangements of the leak
checker output. This will be fixed by a followup commit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10746
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10392
(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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10321
- 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
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
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
