mirror of
https://github.com/Zenithsiz/ftmemsim-valgrind.git
synced 2026-02-12 06:11:37 +00:00
09073639b5
On a big executable, the trunk needs: dinfo: 155844608/106737664 max/curr mmap'd 155572624/102276760 max/curr With the patch, we have: dinfo: 134873088/70389760 max/curr mmap'd 134607808/66717512 max/curr So, peak dinfo memory decreases by 21Mb, and final by 36Mb. The memory decrease is obtained by: * using a dedup pool to store the machine dependent part (cfsi_m) of the cfsi information as this information is highly duplicated. For x86 and arm64, the duplication factor of cfsi machine dependent part is very high (up to a factor 60). For arm64, it is more like a factor 3. A 'variable size' (1, 2 or 4 bytes) is automatically used to identify the cfsi_m, if there is less than or more than 255/64K different cfsi_m. * not storing explicitely the length of a range for which a cfsi_m is to be used: in a large majority of the cases, ranges are consecutive, and so the end of a range is just one byte before the start of the next range. So, we do not store the length of the ranges. If there is a hole between 2 ranges, the hole is stored explicitely as a range in which we have no cfsi_m information. On x86 and amd64, we have quite some holes (something like one hole every 7 cfsi). On arm64, we have very few holes (less than one hole every 50 cfsi). Even with the nr of holes on x86/amd64, it is more memory efficient to store the holes rather than to store the length of each cfsi. * Merging consecutive ranges that have the same cfsi_m info: Many cfsi are "mergeable": there is no hole between 2 cfsi, and their machine dependent part is identical (I guess the unwind info needed by valgrind is subset of the full unwind info, and so, the cfsi entries are not merged by the compiler, but can be merged for simple unwind). Depending on the platform (x86, amd64, arm64) and of the library/object file, we can have a significant nr of mergeable entries. The patch is not very small, but a lot is mechanical changes. The patch has been compiled and tested on x86/amd64/ppc32/ppc64 (but ppc does not use cfsi so that just verifies it compiles). It has been compiled on arm64, and "tested" by launching valgrind on one executable. It has not been compiled on s390 and mips. With some luck, maybe it will compile on these platforms. And if that uses the whole provision of luck for 2014, it might even work on these platforms :). If it does not compile, the fix should be straightforward. Runtime problems might be more tricky (but arm64 "worked out of the box" once x86/amd64 were ok). This has also be tested in an outer/inner setup, to verify no memory leak/bugs. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@14129
Release notes for Valgrind
~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are building a binary package of Valgrind for distribution,
please read README_PACKAGERS. It contains some important information.
If you are developing Valgrind, please read README_DEVELOPERS. It contains
some useful information.
For instructions on how to build/install, see the end of this file.
If you have problems, consult the FAQ to see if there are workarounds.
Executive Summary
~~~~~~~~~~~~~~~~~
Valgrind is a framework for building dynamic analysis tools. There are
Valgrind tools that can automatically detect many memory management
and threading bugs, and profile your programs in detail. You can also
use Valgrind to build new tools.
The Valgrind distribution currently includes six production-quality
tools: a memory error detector, two thread error detectors, a cache
and branch-prediction profiler, a call-graph generating cache abd
branch-prediction profiler, and a heap profiler. It also includes
three experimental tools: a heap/stack/global array overrun detector,
a different kind of heap profiler, and a SimPoint basic block vector
generator.
Valgrind is closely tied to details of the CPU, operating system and to
a lesser extent, compiler and basic C libraries. This makes it difficult
to make it portable. Nonetheless, it is available for the following
platforms:
- X86/Linux
- AMD64/Linux
- PPC32/Linux
- PPC64/Linux
- ARM/Linux
- x86/MacOSX
- AMD64/MacOSX
- S390X/Linux
- MIPS32/Linux
- MIPS64/Linux
Note that AMD64 is just another name for x86_64, and Valgrind runs fine
on Intel processors. Also note that the core of MacOSX is called
"Darwin" and this name is used sometimes.
Valgrind is licensed under the GNU General Public License, version 2.
Read the file COPYING in the source distribution for details.
However: if you contribute code, you need to make it available as GPL
version 2 or later, and not 2-only.
Documentation
~~~~~~~~~~~~~
A comprehensive user guide is supplied. Point your browser at
$PREFIX/share/doc/valgrind/manual.html, where $PREFIX is whatever you
specified with --prefix= when building.
Building and installing it
~~~~~~~~~~~~~~~~~~~~~~~~~~
To install from the Subversion repository :
0. Check out the code from SVN, following the instructions at
http://www.valgrind.org/downloads/repository.html.
1. cd into the source directory.
2. Run ./autogen.sh to setup the environment (you need the standard
autoconf tools to do so).
3. Continue with the following instructions...
To install from a tar.bz2 distribution:
4. Run ./configure, with some options if you wish. The only interesting
one is the usual --prefix=/where/you/want/it/installed.
5. Run "make".
6. Run "make install", possibly as root if the destination permissions
require that.
7. See if it works. Try "valgrind ls -l". Either this works, or it
bombs out with some complaint. In that case, please let us know
(see www.valgrind.org).
Important! Do not move the valgrind installation into a place
different from that specified by --prefix at build time. This will
cause things to break in subtle ways, mostly when Valgrind handles
fork/exec calls.
The Valgrind Developers