Callgrind manual: rewriting start of section about avoding cycles
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 ;-)
* 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
Julian Seward [Tue, 8 May 2007 09:20:25 +0000 (09:20 +0000)]
Add branch-misprediction profiling to Cachegrind. When the (new) flag
--branch-sim=yes is specified, Cachegrind simulates a simple indirect
branch predictor and a conditional branch predictor. The latter
considers both the branch instruction's address and the behaviour of
the last few conditional branches. Return stack prediction is not
modelled.
The new counted events are: conditional branches (Bc), mispredicted
conditional branches (Bcm), indirect branches (Bi) and mispredicted
indirect branches (Bim). Postprocessing tools (cg_annotate, cg_merge)
handle the new events as you would expect. Note that branch
simulation is not enabled by default as it gives a 20%-25% slowdown,
so you need to ask for it explicitly using --branch-sim=yes.
Julian Seward [Sat, 5 May 2007 11:40:35 +0000 (11:40 +0000)]
Fix stack overflow which lead to totally mysterious .bss corruption
and hence to segfaulting in vex on ppc32/64-linux in obscure
circumstances. VKI_MAX_PAGE_SIZE is 64k in recent Valgrinds.
Julian Seward [Tue, 1 May 2007 13:44:08 +0000 (13:44 +0000)]
If gcc supports -fno-stack-protector, use it. This should fix
compilation failures on distros where -fstack-protector is enabled by
default. See #144112.
When doing 'demo' translations for --profile-flags=, make at least
some attempt to discard existing translations first. Otherwise
Cachegrind (rightly) asserts on the basis that it is seeing duplicate
translation requests for the same entry point.
Fix bug 142197: don't free --toolname:foo options after they've been munged,
because tools should be able to assume that they are never freed, just like
other options.
Julian Seward [Mon, 19 Mar 2007 18:38:55 +0000 (18:38 +0000)]
Make ptrace-based launchers able to handle --help, --version etc.
Problem is that --help etc are handled by the tool exe. But a
ptrace-based launch scheme can't run "no program" if the user just
types "valgrind --help" because the launcher depends on starting the
client first and only then attaching valgrind to it using ptrace. So
instead provide a dummy do-nothing program to run when no program is
specified. m_main notices this and acts as if there really had been
no program specified.
This has no effect at all on Linux/ELF program launching.
Julian Seward [Mon, 19 Mar 2007 13:38:11 +0000 (13:38 +0000)]
Document and tidy up one of the more arcane corners of signal
handling: why PRE(sys_sigreturn) has to construct a fake syscall
return value which, when written back to the guest state, leaves it
unchanged. It's only taken me about 3 years to realise why :-)
Fixes to ppc platforms to follow.
Julian Seward [Wed, 14 Mar 2007 11:57:37 +0000 (11:57 +0000)]
Use a 64-bit counter to keep track of the total number of bytes
allocated, rather than SizeT which is word-sized. Your average C++
lardware can easily turn over more than 4G in total in a half hour run
on a 32-bit machine, in which case the counter wraps around.
Julian Seward [Mon, 12 Mar 2007 02:10:23 +0000 (02:10 +0000)]
Add a test for vex ppc64 code generation bug fixed by vex r1739
(When generating 64-bit code, ensure that any addresses used in 4 or 8
byte loads or stores of the form reg+imm have the lowest 2 bits of imm
set to zero, so that they can safely be used in ld/ldu/lda/std/stdu
instructions.)
Julian Seward [Sun, 11 Mar 2007 13:00:34 +0000 (13:00 +0000)]
It appears glibc-2.5's getenv() function steps along environment
strings in 16-bit chunks, which can cause false errors in some cases
(sigh). So do the usual thing and replace it.
Julian Seward [Tue, 27 Feb 2007 18:37:21 +0000 (18:37 +0000)]
Add .eh_frame gunk for VG_(amd64_linux_REDIR_FOR_vgettimeofday) and
VG_(amd64_linux_REDIR_FOR_vgettimeofday) so they can participate in
stack unwinding.
Julian Seward [Tue, 27 Feb 2007 16:52:23 +0000 (16:52 +0000)]
Add limited support for DWARF3 'expressions' in stack-unwind (CFI)
info (DW_CFA_def_cfa_expression, DW_CFA_expression,
DW_CFA_val_expression). Mechanism to support all of these is in place
although only DW_CFA_val_expression is currently connected up.
This is really nasty. The basic idea is to partially evaluate each
expression at the debuginfo-reading time by running it on a stack
machine in which each stack element is an expression tree. If the
expression can be 'run' successfully, the tree (dag, really) remaining
at the top of the stack is massaged and put into the DiCfSI record for
that address range. At unwind time the tree is evaluated if needed.
Such cases are in fact extremely rare and so the vast majority of
unwindings use the same mechanism as before.
As a result of all this:
* some obscure cases in glibc-2.5's libpthread.so unwind when they
didn't before
* --debug-dump=frames produces identical output to that of readelf
for libc-2.5.so and associated libpthread.so
* All the action centers around the new type CfiExpr, which is a
union expression-tree type in the same style as IRExpr et al
* Many dark corners of the CFI reader have been looked at and
(re-)validated
Callgrind: Fix potential buffer overruns with user provided strings
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.
Julian Seward [Sun, 25 Feb 2007 11:51:13 +0000 (11:51 +0000)]
Expandable arrays of arbitrary element type T are a simple, useful
abstraction implemented independently in several places in the code
base (bad!). This commit moves into public view a generic
implementation of it which has been lurking in readxcoff.c for some
time. Currently nothing uses it.
Julian Seward [Sat, 24 Feb 2007 23:29:31 +0000 (23:29 +0000)]
CFI reader: make reading of 'encoded addresses' be much more in
line with the DWARF3 spec and also with binutils/readelf.c:
- Update some comments
- Get rid of kludge_then_addDiCfSI; apparently no longer needed
- Pass the SegInfo's text_bias around in the AddressDecodingInfo,
so that ...
- read_encoded_Addr can set 'base' to the text_bias when handling
DW_EH_PE_absptr. This is the central change of this commit and
appears (to me) to be what DWARF3 requires. (The spec is less
than clear ..)
- don't use read_encoded_Addr to read the FDE arange field since
read_encoded_Addr's adding-on of a 'base' value is meaningless
here - the arange is not an address, but a value saying how many
bytes the FDE covers. Instead just read a little-endian value of
the right size. This is in accordance with DWARF3 and with
readelf.c. Add new function read_le_encoded_literal to make
this possible.
I believe this is all correct, and it's certainly much better than it
was. But given that the DWARF3 spec isn't as formal as it should be,
it's hard to be sure.
Julian Seward [Fri, 23 Feb 2007 10:10:02 +0000 (10:10 +0000)]
Make the frame unwinder able to handle 64-bit DWARF (untested :-(
mostly by a lot of comparison of this code vs that of
binutils-2.17/binutils/dwarf.c vs the relevant specs.
projects / thirdparty / valgrind.git / log
