This commit implements in python a set of GDB commands corresponding to the
Valgrind gdbserver monitor commands.
Basically, the idea is that one GDB command is defined for each valgrind
gdbserver subcommand and will generate and send a monitor command to valgrind.
The python code is auto-loaded by GDB as soon as GDB observes that the valgrind
preload core shared lib is loaded (e.g. vgpreload_core-amd64-linux.so).
This automatic loading is done thanks to the .debug_gdb_scripts section
added in vg_preloaded.c file.
Sadly, the auto-load only happens once valgrind has started to execute the code
of ld that loads this vg_preload file.
I have tried 2 approaches to have the python code auto-loaded when attaching at
startup to valgrind:
* have valgrind gdbserver reporting first to GDB that the executable file is
the tool executable (with a .debug_gdb_scripts section) and then reporting
the real (guest) executable file.
The drawback of this approach is that it triggers a warning/question in GDB
according to the GDB setting 'set exec-file-mismatch'.
* have valgrind gdbserver pretending to be multiprocess enabled, and report
a fake process using the tool executable with a .debug_gdb_scripts section.
The drawback of this is that this always creates a second inferior in GDB,
which will be confusing.
Possibly, we might complete the below message :
==2984378== (action at startup) vgdb me ...
==2984378==
==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2984378== /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem
==2984378== and then give GDB the following command
==2984378== target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378
==2984378== --pid is optional if only one valgrind process is running
with:
==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins.
==2984378== Alternatively, you might load it before with the GDB command:
==2984378== source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py
The following GDB setting traces the monitor commands sent by a GDB valgrind
command to the valgrind gdbserver:
set debug valgrind-execute-monitor on
How to use the new GDB valgrind commands?
-----------------------------------------
The usage of the GDB front end commands is compatible with the
monitor command as accepted today by Valgrind.
For example, the memcheck monitor command "xb' has the following usage:
xb <addr> [<len>]
With some piece of code:
'char some_mem [5];'
xb can be used the following way:
(gdb) print &some_mem
(gdb) $2 = (char (*)[5]) 0x1ffefffe8b
(gdb) monitor xb 0x1ffefffe8b 5
ff ff ff ff ff
0x4A43040: 0x00 0x00 0x00 0x00 0x00
(gdb)
The same action can be done with the new GDB 'memcheck xb' command:
(gdb) memcheck xb 0x1ffefffe8b 5
ff ff ff ff ff
0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00
(gdb)
At this point, you might ask yourself: "what is the interest ?".
Using GDB valgrind commands provides several advantages compared to
the valgrind gdbserver monitor commands.
Evaluation of arguments by GDB:
-------------------------------
For relevant arguments, the GDB command will evaluate its arguments using
the usual GDB evaluation logic, for example, instead of printing/copying
the address and size of 'some_mem', the following will work:
(gdb) memcheck xb &some_mem sizeof(some_mem)
ff ff ff ff ff
0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00
(gdb)
or:
(gdb) p some_mem
$4 = "\000\000\000\000"
(gdb) memcheck xb &$4
ff ff ff ff ff
0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00
(gdb)
This is both easier to use interactively and easier to use in GDB scripts,
as you can directly use variable names in the GDB valgrind commands.
Command completion by GDB:
--------------------------
The usual command completion in GDB will work for the GDB valgrind commands.
For example, typing TAB after the letter 'l' in:
(gdb) valgrind v.info l
will show the 2 "valgrind v.info" subcommands:
last_error location
(gdb) valgrind v.info l
Note that as usual, GDB will recognise a command as soon as it is unambiguous.
Usual help and apropos support by GDB:
--------------------------------------
The Valgrind gdbserver provides an online help using:
(gdb) monitor help
However, this gives the help for all monitor commands, and is not searchable.
GDB provides a better help and documentation search.
For example, the following commands can be used to get various help
or search the GDB Valgrind command online documentation:
help valgrind
help memcheck
help helgrind
help callgrind
help massif
to get help about the general valgrind commands or the tool specific commands.
Examples of searching the online documentation:
apropos valgrind.*location
apropos -v validity
apropos -v leak
User can define aliases for the valgrind commands:
--------------------------------------------------
The following aliases are predefined:
v and vg for valgrind
mc for memcheck
hg for helgrind
cg for callgrind
ms for massif
So, the following will be equivalent:
(gdb) valgrind v.info location &some_mem
(gdb) v v.i lo &some_mem
(gdb) alias Vl = valgrind v.info location
(gdb) Vl &some_mem
Thanks to Hassan El Karouni for the help in factorising the python
code common to all valgrind python commands using a decorator.
I should perhaps just delete these expected. The testcases don't
work well with the stripped libstc++ without debuginfo on FreeBSD.
That means that the --ignore-fn= options don't work to remove
exception handling and iostream allocations and just leave the
tesatcase allocations.
This time with debuginfo removed.
Also update the vgtest files for a couple of massif tests
(and also the expected because of the commmand line change).
Not yet tested these two with debuginfo installed.
There's one remaining
memalign2.c:29:9: warning: unused variable 'piece' [-Wunused-variable]
because of a block of #if FreeBSD for memalign that looks unnecessary
Otherwise all that is left is a few like
warning: unknown warning option '-Wno-alloc-size-larger-than'; did you mean '-Wno-frame-larger-than='? [-Wunknown-warning-option]
because there is no standard for compiler arguments.
GCC12 catches various issues in tests at compile time that we want to
catch at runtime. Also glibc 2.34 deprecated various mallinfo related
functions. Add the relevant -Wno-foobar flags to those tests. In one
case, unit_oset.c, the warning was correct and the uninitialized
variable was explicitly set.
Various tests do things which we want to detect at runtime, like
ignoring the result of malloc or doing a deliberate impossibly large
allocation or operations that would result in overflowing or
truncated strings, that generate a warning from gcc.
In once case, mq_setattr called with new and old attrs overlapping,
this was explicitly fixed, in others -Wno-foobar was added to silence
the warning. This is safe even for older gcc, since a compiler will
ignore any -Wno-foobar they don't know about - since they do know they
won't warn for foobar.
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
massif/tests/deep-D.post.exp-ppc64 was remove in commit 24a94df73
"VG_(get_fnname_kind): Recognize gcc "optimized" below main functions."
but was still listed in massif/tests/Makefile.am (EXTRA_DIST). Causing
make dist to fail.
The VG_(get_fnname_kind) function detects some special "below main"
function names. Specifically __libc_start_main and generic_start_main
both of which are used to call the actual main () function from the
application. We already recognized one variant, generic_start_main.isra.0,
but only for powerpc. Recognize all possibly specialed optimized variants
gcc can produce by simply checking for the function name with dot as
prefix. This fixes the memcheck/tests/supp_unknown.vgtest and
massif/tests/deep-D.vgtest with gcc 11.
We can now also get rid of the special cases in
massif/tests/deep-D.post.exp-ppc64 and memcheck/tests/supp_unknown.supp.
https://bugs.kde.org/show_bug.cgi?id=430158
manpages-index.xml is just to easily get at each individual man page
with xsltproc. It wasn't a complete docbookx xml file. Now that it is
we can validate it with xmllint. It doesn't fully validate, but we
are close.
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.
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
The change in the glibc version (2.27 -> 2.28) results in one additional
function call being present in the backtrace for mips64, which leads to the
line to be checked to be out of bounds.
Changed the post line in mmapunmap.vgtest to work around this.
This fixes massif/tests/mmapunmap failure on mips64.
Patch by Stefan Maksimovic.
This commit thoroughly overhauls DHAT, moving it out of the
"experimental" ghetto. It makes moderate changes to DHAT itself,
including dumping profiling data to a JSON format output file. It also
implements a new data viewer (as a web app, in dhat/dh_view.html).
The main benefits over the old DHAT are as follows.
- The separation of data collection and presentation means you can run a
program once under DHAT and then sort the data in various ways. Also,
full data is in the output file, and the viewer chooses what to omit.
- The data can be sorted in more ways than previously. Some of these
sorts involve useful filters such as "short-lived" and "zero reads or
zero writes".
- The tree structure view avoids the need to choose stack trace depth.
This avoids both the problem of not enough depth (when records that
should be distinct are combined, and may not contain enough
information to be actionable) and the problem of too much depth (when
records that should be combined are separated, making them seem less
important than they really are).
- Byte and block measures are shown with a percentage relative to the
global count, which helps gauge relative significance of different
parts of the profile.
- Byte and blocks measures are also shown with an allocation rate
(bytes and blocks per million instructions), which enables comparisons
across multiple profiles, even if those profiles represent different
workloads.
- Both global and per-node measurements are taken at the global heap
peak ("At t-gmax"), which gives Massif-like insight into the point of
peak memory use.
- The final/liftimes stats are a bit more useful than the old deaths
stats. (E.g. the old deaths stats didn't take into account lifetimes
of unfreed blocks.)
- The handling of realloc() has changed. The sequence `p = malloc(100);
realloc(p, 200);` now increases the total block count by 2 and the
total byte count by 300. Previously it increased them by 1 and 200.
The new handling is a more operational view that better reflects the
effect of allocations on performance. It makes a significant
difference in the results, giving paths involving reallocation (e.g.
repeated pushing to a growing vector) more prominence.
Other things of note:
- There is now testing, both regression tests that run within the
standard test suite, and viewer-specific tests that cannot run within
the standard test suite. The latter are run by loading
dh_view.html?test=1 in a web browser.
- The commit puts all tool lists in Makefiles (and similar files) in the
following consistent order: memcheck, cachegrind, callgrind, helgrind,
drd, massif, dhat, lackey, none; exp-sgcheck, exp-bbv.
- A lot of fields in dh_main.c have been given more descriptive names.
Those names now match those used in dh_view.js.
Author: Nicholas Nethercote <nnethercote@mozilla.com>
Use inlined frames in Massif XTree output.
This makes Massif's output much easier to follow.
The commit also removes a -1 used on all Massif stack frame addresses.
There was a big comment questioning the presence of that -1, and with it
gone the addresses now match those produced by DHAT.
Sometimes, at least on arm platforms, we get a stack trace with
only one function.
When this happens and massif removes the top fn, we end up trying
to create an execontext of 0 ips, as the only fn is removed,
and an execontext of 0 ips causes the assert in m_execontext.c
So, do whatever to avoid to crash when having a single fn stacktrace.
The whatever means use a null execontext, which is an execontext
of one single address 0x0.
Note that this is just to bypass the crash.
What is shown by massif is not very nice (but what could we show ?).
Note that instead of using such a null execontext, we could rather
just keep the single ips. But that might create a lot of single fn
entries in the xtree and/or show undesired functions.
So, we the null execontext, which is shown as 0xFFFFFFFFFFFFFFFF ???
in the massif output.
Tested on amd64 by artificially creating stacktrace of one fn.
* 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.
massif/tests/mmapunmap on ppc now indicates a below main function.
Note: this ppc53 specific file is needed because the valgrind stack unwinder
does not properly unwind in main.
At the mmap syscall, gdb backtrace gives:
Breakpoint 3, 0x00000000041dbae0 in .__GI_mmap () from /lib64/libc.so.6
(gdb) bt
while the valgrind stack trace gives:
Thread 1: status = VgTs_Runnable (lwpid 64207)
==64207== at 0x41DBAE0: mmap (in /usr/lib64/libc-2.17.so)
==64207== by 0x10000833: f (mmapunmap.c:9)
==64207== by 0x40E6BEB: (below main) (in /usr/lib64/libc-2.17.so)
client stack range: [0x1FFEFF0000 0x1FFF00FFFF] client SP: 0x1FFF00ECE0
valgrind stack top usage: 15632 of 1048576
Currently, --ignore-fn is only matched with the top IP entries that
have a fnname. With this change, we first search for the first IP that
has a fnname.
This e.g. allows to ignore the allocation for a stacktrace such as:
0x1 0x2 0x3 fn_to_ignore otherfn
This is then used in massif c++ tests new-cpp and overloaded-new to ignore
the c++ libstdc++ allocation similar to:
==10754== 72,704 bytes in 1 blocks are still reachable in loss record 10 of 10
==10754== at 0x4C2BBCD: malloc (vg_replace_malloc.c:299)
==10754== by 0x4EC39BF: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22)
==10754== by 0x400F8A9: call_init.part.0 (dl-init.c:72)
==10754== by 0x400F9BA: call_init (dl-init.c:30)
==10754== by 0x400F9BA: _dl_init (dl-init.c:120)
==10754== by 0x4000C59: ??? (in /lib/x86_64-linux-gnu/ld-2.24.so)
Exception specifications are a deprecated feature in C++11 and gcc 7
complains about these specifications. Hence remove these specifications.
This patch avoids that gcc reports the following:
warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16360
The previous code was removing the massif preload (when --pages-as-heap=yes)
by replacing the entry with spaces.
This is not very clear, and I suspect this gives problems with the
android linker, which seems to use such a space entry as a real entry
to load (and then fails to start the application).
This patch really removes the entry, by shifting the characters.
Tested on amd64/debian.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16306
Remove redefinition of typedef ‘Time’ already defined in pub_tool_xtree.h
This fixes warning/error:
ms_main.c:633:14: warning: redefinition of typedef ‘Time’ [-Wpedantic]
typedef Long Time;
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16174
* update massif code so as to replace the massif specific XTree implementation
by calls to pub_tool_xtree.h
This improves the massif performance in CPU (a few percents to a factor
2 gained, depending on the implementation). The memory use is also
decreased.
With this patch, massif behaves similarly to the previous implementation.
The differences are:
* some massif stats output have changed, as the new implementation
differs completely from the previous one.
* when 2 'branches' of the call tree have consumed the same amount
of heap, the order in which the branches are output in the massif
output file can differ between the old and new implementation.
No other functional difference is expected, waiting for new bugs to
be discovered.
* Also add support for xtree memory profiling and xtmemory gdbsrv monitor
command in massif :
* massif will produce xtree memory profiling according to the options
--xtree-memory.
* addition of the xtmemory gdbserver monitor command.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16129
The reported backtrace on ppc64 platform reports "generic_start_main.isra.0"
in the backtrace, where other platforms typically see "main". Adjust the
vgtest file to handle this variation. This is similar to existing changes
as seen in deep-D.post.exp
FORGOT to add the file massif/tests/mmapunmap.post.exp-ppc64 before doing
commit 15950.
Bugzilla 368461
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15955
The reported backtrace on ppc64 platform reports "generic_start_main.isra.0"
in the backtrace, where other platforms typically see "main". Adjust the
vgtest file to handle this variation. This is similar to existing changes
as seen in deep-D.post.exp
Bugzilla 368461
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15950
for libstdc++ from gcc5.
Even with fix for bug 345307 we still see allocations for
the emergency pool in libstdc++ which skew the expected results.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15847
from libstdc++ when available, similar to existing __libc_freeres().
New option --run-cxx-freeres=<yes|no> can be used to change whether
this cleanup function is called or not.
Note that __gnu_cxx::__freeres() is currently available
only in gcc 6. It is not yet decided what to do about
libstdc++ from gcc 5.
Tracked under https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945
for libstdc++.
Fixes BZ#345307 (partially).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15840
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
On Solaris and Linux, mmap() is an optimized function without
prologue and epilogue. However, Solaris libc does not currently
bear any DWARF CFI. Therefore stack chain unwinder grabs only
two entries: IP inside mmap() and return address from the previous
frame which points inside _start(), right after where main()
is invoked. By introducing an intermediate function f(), main()
is now visible in the stack trace even on Solaris.
n-i-bz
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15749
ms_unrecord_page_mem was wrongly taking the (possible) peak snapshot
when unrecording the last block.
But the peak snapshot will be detected when unrecording the first block
of an munmap, not when unrecording the last block.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15745
--pid:
i.e. debug output. Asserts originating from the address space
manager look exactly like that and we do not want to filter those
out by default.
Remove some specialised filter scripts that are no longer needed
and update a few .vgtest files accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15519
Add a deep-D test .exp values for ppc64.
Depending on the system and the systems endianness, there are variances
in the library reference, and to the specific line number in the library.
I was able to add and modify existing filters to cover most of the variations,
but did need to add a .exp to cover the additional call stack entry as seen
on power.
This change allows the ppc64 targets to pass the massif/deep-D test.
This patch fixes Vagrind bugzilla 347686
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15228
Update the massif/big-alloc test for ppc64*.
In comparison to the existing .exp files, the time,total,extra-heap
values generated on ppc64* vary from the other architectures.
This .exp allows the ppc64 targets to pass the test.
This patch fixes Vagrind bugzilla 347322.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15226
Valgrind aspects, to match vex r3124.
See bug 339778 - Linux/TileGx platform support to Valgrind
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15080
