cachegrind callgrind dhat exp-bbv gdbserver_tests massif none mpi shared
Mostly these are just updates (and new testcases) under new/tests
The other directories have just #ifdef changes
This is a supplement to commit 86277041
To improve its results, Callgrind does special handling for
the runtime linker entry point to resolve symbols. However,
it only used the exact symbol name "_dl_runtime_resolve",
as well as specific machine code templates (when the runtime
linker was stripped from symbol names) as basis.
Recent glibc added multiple similar symbol names as variants,
such as _dl_runtime_resolve_xsave.
The above-mentioned commit 86277041 solves this by extending
the check for machine code templates for specific Linux
distributions.
This patch extends this for more architectures and variants
by checking if a function starts with "_dl_runtime_resolve".
Furthermore, the original function names of the variants
still are visible in the output (and not forced to the prefix).
While the heuristic that every function symbol starting
with the prefix "_dl_runtime_resolve" as being an entry point
into the runtime linker for resolving a function address may
be a bit rough, this prefix is not expected to be used often in
other source code for anything else.
The worst case is a slightly misleading call graph only
visible in a very specific situation: if the wrongly-detected
function does a tail call (ie instead of returning, jumping
to another function), it will be shown as 2 calls in a row
from the original caller.
Newer glibc have alternate ld.so _ld_runtime_resolve functions.
Namely _dl_runtime_resolve_xsave and _dl_runtime_resolve_xsavec
This patch recognizes the xsave, xsvec and fxsave variants and
changes callgrind so that any variant counts as _dl_runtime_resolve.
Original patch by paulo.cesar.pereira.de.andrade@gmail.comhttps://bugs.kde.org/show_bug.cgi?id=415293
This makes the rule for xmllint easier since it doesn't need to
override the DTD to validate against. It also helps with other tools
tryinf to process the docbookx xml files.
* removes --vex-guest-chase-cond=no|yes. This was never used in practice.
* rename --vex-guest-chase-thresh=<0..99> to --vex-guest-chase=no|yes. In
otherwords, downgrade it from a numeric flag to a boolean one, that can
simply disable all chasing if required. (Some tools, notably Callgrind,
force-disable block chasing, so this functionality at least needs to be
retained).
C++ function names can contain substrings like "{lambda()#1}". But
callgrind_annotate and cg_annotate interpret the '#'-character as a
comment marker anywhere on each input line, and thus truncate such names
there.
On the other hand, the documentation in docs/cl-format.xml, states:
Everywhere, comments on own lines starting with '#' are allowed.
This seems to imply that a comment line must start with '#' in the first
column. Thus skip exactly such lines in the input file and don't handle
'#' as a comment marker anywhere else.
Signed-off-by: Philippe Waroquiers <philippe.waroquiers@skynet.be>
callgrind_annotate expects the 'events:' line to be the last line
of the header of a Part.
When event: lines are after the events: line, these event: lines are
handled by the calllgrind_annotate body line logic, that does not recognises
them and generates warnings such as:
WARNING: line 18 malformed, ignoring
line: 'event: sysTime : sysTime (elapsed ns)'
WARNING: line 19 malformed, ignoring
line: 'event: sysCpuTime : sysCpuTime (system cpu ns)'
So, output event: lines before events: line.
- The command option --collect-systime has been enhanced to specify
the unit used to record the elapsed time spent during system calls.
The command option now accepts the values no|yes|msec|usec|nsec,
where yes is a synonym of msec. When giving the value nsec, the
system cpu time of system calls is also recorded.
Note that the nsec option is not supported on Darwin.
Sync VEX/LICENSE.GPL with top-level COPYING file. We used 3 different
addresses for writing to the FSF to receive a copy of the GPL. Replace
all different variants with an URL <http://www.gnu.org/licenses/>.
The following files might still have some slightly different (L)GPL
copyright notice because they were derived from other programs:
- files under coregrind/m_demangle which come from libiberty:
cplus-dem.c, d-demangle.c, demangle.h, rust-demangle.c,
safe-ctype.c and safe-ctype.h
- coregrind/m_demangle/dyn-string.[hc] derived from GCC.
- coregrind/m_demangle/ansidecl.h derived from glibc.
- VEX files for FMA detived from glibc:
host_generic_maddf.h and host_generic_maddf.c
- files under coregrin/m_debuginfo derived from LZO:
lzoconf.h, lzodefs.h, minilzo-inl.c and minilzo.h
- files under coregrind/m_gdbserver detived from GDB:
gdb/signals.h, inferiors.c, regcache.c, regcache.h,
regdef.h, remote-utils.c, server.c, server.h, signals.c,
target.c, target.h and utils.c
Plus the following test files:
- none/tests/ppc32/testVMX.c derived from testVMX.
- ppc tests derived from QEMU: jm-insns.c, ppc64_helpers.h
and test_isa_3_0.c
- tests derived from bzip2 (with embedded GPL text in code):
hackedbz2.c, origin5-bz2.c, varinfo6.c
- tests detived from glibc: str_tester.c, pth_atfork1.c
- test detived from GCC libgomp: tc17_sembar.c
- performance tests derived from bzip2 or tinycc (with embedded GPL
text in code): bz2.c, test_input_for_tinycc.c and tinycc.c
When a callgrind dump file contains no event (at all I think),
then callgrind_annotate can produce the below error messages:
Ir sysCount sysTime file:function
--------------------------------------------------------------------------------
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
. . . /build/glibc-yWQXbR/glibc-2.24/csu/../csu/libc-start.c:(below main) [/lib/x86_64-linux-gnu/libc-2.24.so]
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
. . . /build/glibc-yWQXbR/glibc-2.24/elf/../sysdeps/x86_64/dl-trampoline.h:_dl_runtime_resolve_xsave [/lib/x86_64-linux-gnu/ld-2.24.so]
Use of uninitialized value in numeric gt (>) at ../trunk_untouched/Inst/bin/callgrind_annotate line 957.
.....
The above can be produced by:
run sleep 100 under callgrind.
take some callgrind dumps after the startup.
./Inst/bin/callgrind_annotate --threshold=1 callgrind.out.31377.2
Check that the value is defined before doing the comparison.
Note: callgrind_annotate shows functions which have undefined costs
for all events (and I guess it would also show functions that have zero
costs for all events).
Maybe it would be better to not show at all such functions, rather than
show them with all '.'.
Because it's very useful. As part of this, the "percentage of events
annotated" numbers at the bottom of the output is changed to "events
annotated" so that --show-percs doesn't compute a percentage of a
percentage.
Example output lines:
```
4,967,137,442 (100.0%) PROGRAM TOTALS
4,543 (25.23%) 17,566 ( 0.43%) 47,993 ( 0.92%) /build/glibc-OTsEL5/glibc-2.27/elf/dl-lookup.c
1 ( 0.01%) 2,000,001 (49.29%) 3,000,004 (57.36%) for (int i = 0; i < 1000000; i++) {
```
The commit also adds some much-needed tests for cg_annotate and
callgrind_annotate.
We did not set the call cost counters in CLG_(zero_bbcc) to zero,
which gets called by requests to set counters to zero
- via client request
- when entering a function if configured so
- via gdb monitor command (used by callgrind_control -z)
Counters are also set to zero after they are dumped out to a file.
This does not use CLG_(zero_bbcc), and was doing the right thing.
This fixes bug 392449.
Search for a vgdb executable in the same dir as callgrind_control perl file.
If not found, search for a vgdb executable in a sibling coregrind dir
(covers the case of : perl callgrind/callgrind_control)
Otherwise, just hope we find a vgdb executable in PATH
On majority of architectures size of long matches register width.
On mips n32 size of long is 32 bits and register width is 64 bits.
Valgrind is written with assumption that long size matches register
width. This is the reason why both UWord for Valgrind and HWord for VEX
match size of long. Long size differs from register size on mips n32 ABI.
Introducing RegWord type that will match size of registers.
Part of the changes required for BZ issue - #345763.
Contributed by:
Tamara Vlahovic and Dimitrije Nikolic.
* Addition of a new configure option --enable-lto=yes or --enable-lto=no
Default value is --enable-lto=no, as the build is significantly slower,
so is not appropriate for valgrind development : this should be used
only on buildbots and/or by packagers.
* Some files containins asm functions have to be compiled without lto:
coregrind/m_libcsetjmp.c
coregrind/m_main.c
If these are compiled with lto, that gives undefined symbols at link time.
The files to compile without lto are
coregrind/m_libcsetjmp.c
coregrind/m_main.c
To compile these files with other options, a noinst target lib is defined.
The objects of this library are then added to the libcoregrind.
* memcheck/mc_main.c : move the handwritten asm helpers to mc_main_asm.c.
This avoids undefined symbols on some toolchains. Due to this,
the preprocessor symbols that activate the fast or asm memcheck helpers
are moved to mc_include.h
Platforms with handwritten helpers will also have the memcheck primary
map defined non static.
* In VEX, auxprogs/genoffsets.c also has to be compiled without lto,
as the asm produced by the compiler is post-processed to produce
pub/libvex_guest_offsets.h. lto not producing asm means the generation
fails if we used -flto to compile this file.
* all the various Makefile*am are modified to use LTO_CFLAGS for
(most) targets. LTO_CFLAGS is empty when --enable-lto=no,
otherwise is set to the flags needed for gcc.
If --enable-lto=no, LTO_AR and LTO_RANLIB are the standard AR and RANLIB,
otherwise they are the lto capable versions (gcc-ar and gcc-ranlib).
* This has been tested on:
debian 9.4/gcc 6.3.0/amd64+x86
rhel 7.4/gcc 6.4.0/amd64
ubuntu 17.10/gcc 7.2.0/amd64+x86
fedora26/gcc 7.3.1/s390x
No regressions on the above.
KCachegrind currently uses a quick format detection before
actually loading a file, and checks for a line starting with
"events:" in the first 2kB for that. This obviously is fragile,
as shown by an internal bug report by Philippe: before the
"events" line, Callgrind puts a "cmd:" line with the command
line. If this is very long, the detection fails and the file
does not get loaded at all.
While KCachegrind would not need to have this quick format
check at all, it is useful if multiple input format filters
get supported at some point, to automatically select the
correct filter.
Further, for the "file" command, for file managers and
desktop environments, having an unique way to detect a
file format is important.
It is not too late to fix this issue for the callgrind format.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16196
* callgrind_annotate: ignore the lines giving the long names of the
events: such lines are used by kcachegrind for the GUI, so are better
accepted (and ignored) by callgrind_annotate
* Document in callgrind_annotate manual that thresholds can be given
per event kind.
* Avoid a division by zero in callgrind_annotate, for 'special data'
such as produced by (some) xtrees.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16125
At many places, we have:
VG_(fun(a,b,c))
instead of
VG_(fun)(a,b,c)
So, fix these cases, found using:
grep -n -i -e 'VG_([a-z][a-z0-9_]*[^a-z0-9_)]' *.c */*.c */*/*.c
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15776
Escape newlines in command arguments for "cmd:" header field in dumps
We could do unescaping in callgrind_annotate, but a escaped command
even seems better there.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14947
made from file-backed mappings (AOT code, basically) that is different
from the default behaviour as specified by --vex-iropt-register-updates.
New flag is --px-file-backed=, with the same possible args as
--vex-iropt-register-updates has.
Add a new flag --px-default, which is a short alias for
--vex-iropt-register-updates.
Add one line of stats output when --stats=yes, showing counts of how
many translations have been made under each of the 4 different PX
optimisation settings.
No user-visible change if you don't use the new flags.
Relies on VEX API change in r3084.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14906
only allowed to be called in certain contexts which is
enforced at runtime.
Change callgrind accordingly.
New header file pub_tool_transtab.h added.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14867
When the info struct for a BB is created, we use the first guest
instruction address as key to insert the info into a hash table.
We should do the same when discarding.
This actually is not a real problem, as Callgrind obviously
is used very rarely with redirections. But we should be consistent
with cachegrind.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14856
