It's reorg only. No new cache autodetection stuff has been added.
coregrind
pub_tool_cpuid.h is removed as it is no longer exposed to tools.
Its contents has moved to pub_core_cpuid.h.
New file: coregrind/m_cache.c to contain the autodetect code for
cache configurations and define other cache characteristics that
cannot be autodetected (i.e. icaches_maintain_coherence). Most of
cg-arch/x86-amd64.c was moved here. The cache detection code for
x86-64 needs to be fixed to properly initialise VexCacheInfo. It
currently has cachegrind bias.
m_cache.c exports a single function (to coregrind):
VG_(machine_get_cache_info)(VexArchInfo *vai)
This function is called from VG_(machine_get_hwcaps) after hwcaps have
been detected.
cachegrind
Remove cachegrind/cg-{ppc32,ppc43,arm,mips32,s390x,x86-amd64}.c
With the exception of x86/mamd64 those were only establishing a
default cache configuration and that is so small a code snippet that
a separate file is no longer warranted. So, the code was moved to
cg-arch.c. Code was added to extract the relevant info from
x86-amd64.
New function maybe_tweak_LLc which captures the code to massage the
LLc cache configuration into something the simulator can handle. This
was originally in cg-x86-amd64.c but should be used to all architectures.
Changed warning message about missing cache auto-detect feature
to be more useful. Adapted filter-stderr scripts accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13028
Performance improvements from 4 to 8% obtained on amd64 on the perf tests by:
1. using UNLIKELY inside tracing macros
2. avoid calling CLG_(switch_thread)(tid) on the hot patch setup_bbcc
unless tid differs from CLG_(current_tid).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12939
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
memcheck.h) by changing a bunch of VALGRIND_DO_CLIENT_REQUEST_EXPR
into VALGRIND_DO_CLIENT_REQUEST_STMT for cases where the return value
of the former would be unused. (Bart Van Assche, bart.vanassche@gmail.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12226
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
Patch by Philippe Waroquiers, slightly changed.
This actually was a regression from 3.6.1, but the patch
also improves on printed messages, and refactors common
code between cachegrind and callgrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12013
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
If valgrind is called with absolute path (as qtcreator does),
callgrind_control found nothing, as it looked for
"... for valgrind ...", thus breaking qtcreator.
This also fixes expected behavior with client commands called with
absolute path. For "/usr/bin/valgrind --tool callgrind /usr/bin/foo",
running "callgrind_control foo" should catch this callgrind command.
Instead, you previously had to include the absolute path.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11905
Same functionality, apart from "-l" to show "long information".
This only printed the current working directory of the callgrind run,
which currently is not available any longer, but not really needed.
The port to vgdb has an important benefit:
callgrind can now be controlled by callgrind_control also when
the client program is blocked/sleeping in a system call. This was
not possible before as a command file was polled only while the
client was running.
Ubuntu by default restricts PTRACE (used by vgdb) to parent processes,
making Ubuntu show similar behavior as before: vgdb is not allowed
to attach by PTRACE when the client is blocked/sleeping, so
callgrind_control works similar to before this change on Ubuntu.
A final patch, which gets rid of command file polling, will be
submitted after Valgrind 3.7, as KCachegrind currently writes
command files directly, and needs to be changed to rely on
callgrind_control instead.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11867
--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
swapping the roles of the VALGRIND_DO_CLIENT_REQUEST() and
VALGRIND_DO_CLIENT_REQUEST_EXPR() macros. Also, many __attribute__((unused))
declarations on variables have been eliminated. Closes#269778.
Note: so far this patch has been tested on x86/Linux, amd64/Linux and
ppc64/Linux but not yet on any other supported CPU/OS combination.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11755
For calls (structure jCC), Callgrind maintains for the source
both the BBCC (counter array for the source context of the call, which
includes the BB of the source call position), as well as a jump
number in the source BB to reconstruct the guest instruction address
of the call. In setup_bbcc, this jump number is stored in <passed>, and
used when creating a new jCC on a call.
The value of <passed> got out of sync when we simulate a real jump
between different functions as return/call pair: the call source was
reset for the popped jCC, but not <passed>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11579
When unwinding needs to be done because the stack pointer is reset
(e.g. by a longjmp), it makes no sense to interprete the control
flow change as call, but should be seen as a return.
This indirectly fixes bug 246152. Unwinding potentially changes the
exec state, which is unique for threads, but also for signal handlers.
E.g. this is true for a longjmp out of a signal handler. Exec state
changes modify members of struct CLG_(current_state), such as
CLG_(current_state).bbcc and CLG_(current_state).jmps_passed, which
are backed in CLG_(setup_bbcc)() by last_bbcc and passed, respectivly.
On a exec state change, these local vars go out of sync, and lead
to invalid data passed to CLG_(push_call_stack)() for handling a call,
which triggered data corruption, and the symptoms seen in bug 246152.
As in the given situation, there is no call anymore, there is no call
into CLG_(push_call_stack)(), and the corruption (or since last commit
the failed assertion) is not triggered any more.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11524
This is part 1 of the fix to bug 246152, and makes the bug
reproducable as failed assertion also on Ubuntu 10.10 on 64bit
machines. However, the test needs to be compiled 32bit (-m32).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11523
Correct a beginners PERL bug ;-)
Need to create new arrays, not just copying references to ARRAYs
around, which are modified later on...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11497
filtering out thereof, so as to make Cachegrind and Callgrind
pass their regressiont tests on ARM-Linux.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11433
of the L2 cache. This is to accommodate machines with three levels of
cache. We still only simulate two levels, the first and the last.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11404
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
messages now begin with "valgrind: ", and they're more often printed before
the preamble. This required introducing a new message kind, Vg_FailMsg, and
functions VG_(fmsg) and VG_(fmsg_bad_option), and removing
VG_(err_bad_option).
Where we used to have horrible output like this:
[ocean:~/grind/ws2] vg5 --tool=massif --threshold=101 date
==31877== Massif, a heap profiler
==31877== Copyright (C) 2003-2010, and GNU GPL'd, by Nicholas Nethercote
==31877== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==31877== Command: date
==31877==
==31877== --threshold must be between 0.0 and 100.0
valgrind: Bad option '--threshold'; aborting.
valgrind: Use --help for more information.
We now have nice output like this:
[ocean:~/grind/ws2] vg2 --tool=massif --threshold=101 date
valgrind: Bad option: --threshold=101
valgrind: --threshold must be between 0.0 and 100.0
valgrind: Use --help for more information or consult the user manual.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11209
