Ensure this documentation file is included in tarball.
Fixes: 9f3d49a ("Create 3.10.0 section in NEWS, add (first draft of) README_DEVELOPERS_processes")
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
This approach is utilized consistently throughout the file, and would make
alphabetical reordering easier. Adopt it here as well.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Avoid use of two manners of setting automake configuration options,
and consolidate them into AM_INIT_AUTOMAKE macro.
Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
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.
Create a file vgversion_dist.h in the tarball.
This file is not deleted by make clean
Change auxprogs/make_or_upd_vgversion_h to use vgversion_dist.h if it is
available.
Add some missing quotes to auxprogs/make_or_upd_vgversion_h
Patch by Matthias Schwarzott <zzam@gentoo.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16398
Make sure to include the builddir include directory to find the
generated vgversion.h. Make include/vgversion.h a .PHONY target
so it always gets regenerated even if the file is already there.
Make sure to run svnversion in the srcdir.
Patch by Matthias Schwarzott <zzam@gentoo.org>
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16397
Patch by Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>.
Partial fix. make && make check now works with builddir != srcdir.
But make regtest doesn't yet.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13949
are not against the grain.
Wrap this script together with 'check_makefile_consistency' into
'post_regtest_checks' and invoke that from the toplevel Makefile. So we can
easily add new checkers in the future.
Add a new make target 'post-regtest-checks' to just run those checks
and nothing else.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13570
The tester is located in memcheck/tests/vbit-test.
It needs the following support on the valgrind / VEX side:
(1) a new client request VG_USERREQ__VEX_INIT_FOR_IRI
(2) a new "special instruction" on all architectures inserted via
VALGRIND_VEX_INJECT_IR
(3) VEX changes to detect the special insn and insert IR (ir_inject.c)
The README file in vbit-test has some more information.
See also VEX r2490. Fixes bugzilla #300102.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12906
default memory limits when building the PDF docs. Fixes#304754.
(Mark Wielaard, mjw@redhat.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12863
in .S files. Also included here is some cleanup, including a reversion
of r10378. Fixes bugzilla #197914.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12555
* configure.in support
* new supp file darwin11.supp
* comment out many intercepts in mc_replace_strmem.c and
vg_replace_malloc.c that are apparently unnecessary for Darwin
* add minimal handling for the following new syscalls and mach traps:
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
* wqthread_hijack on amd64-darwin: deal with
tst->os_state.pthread having an apparently different offset,
which caused an assertion failure
* m_debuginfo: for 32 bit processes on Lion, use the DebugInfoFSM
cleanup added in r12041/12042 to handle apparently new dyld
behaviour, which is to map text areas r-- first and only
vm_protect them later to r-x.
The following cleanups remain to be done
* remove apparently pointless, commented out wrapper macro
invokations in mc_replace_strmem.c, eg
//MEMMOVE(VG_Z_DYLD, memmove)
(or determine that they are still necessary, and uncomment)
* ditto in vg_replace_malloc.c, plus general VGO_darwin cleanups
there
* write proper syscall wrappers for
mach_port_set_context
task_get_exception_ports
getaudit_addr
psynch_mutexwait
psynch_mutexdrop
psynch_cvbroad
psynch_cvsignal
psynch_cvwait
psynch_rw_rdlock
psynch_rw_wrlock
psynch_rw_unlock
psynch_cvclrprepost
These are currently just no-ops and may be causing Memcheck to
report false undef-value errors
* figure out why it doesn't work properly unless built with gcc-4.2 on
Lion.
gcc-4.2 is the "normal" gcc (i686-apple-darwin11-gcc-4.2.1). Plain
gcc is the hybrid gcc-front-end clang-back-end thing
(i686-apple-darwin11-llvm-gcc-4.2). Whereas on Snow Leopard, plain
gcc is the normal gcc.
The symptoms of the failure are that wqthread_hijack in
syswrap-amd64-linux.c hits this /*NOTREACHED*/ vg_assert(0); right
at the end (you need a pretty complex threaded app to trigger this),
which makes me think that either ML_(wqthread_continue_NORETURN) or
call_on_new_stack_0_1 do return, which they are not expected to.
* figure out if some of the uninitialised value errors reported in
system libraries on are caused by Memcheck being confused by LLVM
generated code, as per bug #242137
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12043
block beyond the original request weren't copied. They are now. This is
important because a program could use malloc_usable_size to gain legitimate
access to those extra bytes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11956
is a heap profiler that is complementary to Massif. DHAT tracks heap
allocations, and connects which memory accesses are to which blocks.
It can find the following information:
* total allocation and max liveness
* average block lifetime (# instructions between allocation and
freeing)
* average number of reads and writes to each byte in the block
("access ratios")
* average of longest interval of non-access to a block, also
measured in instructions
* which fields of blocks are used a lot, and which aren't
(hot-field profiling)
Using these stats it is possible to identify allocation points with
the following characteristics:
* potential process-lifetime leaks (blocks allocated by the point just
accumulate, and are freed only at the end of the run)
* excessive turnover: points which chew through a lot of heap, even if
it is not held onto for very long
* excessively transient: points which allocate very short lived blocks
* useless or underused allocations: blocks which are allocated but not
completely filled in, or are filled in but not subsequently read.
* blocks which see extended periods of inactivity. Could these
perhaps be allocated later or freed sooner?
* blocks with inefficient layout (hot fields spread out over
multiple cache lines), or with alignment holes
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11431
svn merge -r11143:HEAD svn://svn.valgrind.org/valgrind/branches/MACOSX106
There were some easy-to-resolve conflicts.
Then I had to fix up coregrind/link_tool_exe*.in -- those files had been
added independently on both the trunk and the branch, AFAICT. I just
overwrote the trunk versions with the branch versions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11194
following improvements:
- Arch/OS/platform-specific files are now included/excluded via the
preprocessor, rather than via the build system. This is more consistent
(we use the pre-processor for small arch/OS/platform-specific chunks
within files) and makes the build system much simpler, as the sources for
all programs are the same on all platforms.
- Vast amounts of cut+paste Makefile.am code has been factored out. If a
new platform is implemented, you need to add 11 extra Makefile.am lines.
Previously it was over 100 lines.
- Vex has been autotoolised. Dependency checking now works in Vex (no more
incomplete builds). Parallel builds now also work. --with-vex no longer
works; it's little use and a pain to support. VEX/Makefile is still in
the Vex repository and gets overwritten at configure-time; it should
probably be renamed Makefile-gcc to avoid possible problems, such as
accidentally committing a generated Makefile. There's a bunch of hacky
copying to deal with the fact that autotools don't handle same-named files
in different directories. Julian plans to rename the files to avoid this
problem.
- Various small Makefile.am things have been made more standard automake
style, eg. the use of pkginclude/pkglib prefixes instead of rolling our
own.
- The existing five top-level Makefile.am include files have been
consolidated into three.
- Most Makefile.am files now are structured more clearly, with comment
headers separating sections, declarations relating to the same things next
to each other, better spacing and layout, etc.
- Removed the unused exp-ptrcheck/tests/x86 directory.
- Renamed some XML files.
- Factored out some duplicated dSYM handling code.
- Split auxprogs/ into auxprogs/ and mpi/, which allowed the resulting
Makefile.am files to be much more standard.
- Cleaned up m_coredump by merging a bunch of files that had been
overzealously separated.
The net result is 630 fewer lines of Makefile.am code, or 897 if you exclude
the added Makefile.vex.am, or 997 once the hacky file copying for Vex is
removed. And the build system is much simpler.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@10364
