From: Julian Seward Date: Wed, 13 Oct 2010 21:47:29 +0000 (+0000) Subject: Documentation update for 3.6.0 (not including NEWS). X-Git-Tag: svn/VALGRIND_3_6_0~17 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b43eec121906f112438dd3e866c4f3ac2cf5beb7;p=thirdparty%2Fvalgrind.git Documentation update for 3.6.0 (not including NEWS). git-svn-id: svn://svn.valgrind.org/valgrind/trunk@11440 --- diff --git a/AUTHORS b/AUTHORS index dbfd904ed4..de0c9c7ddd 100644 --- a/AUTHORS +++ b/AUTHORS @@ -1,7 +1,8 @@ -Julian Seward was the original founder, designer and author of Valgrind, -created the dynamic translation frameworks, wrote Memcheck and 3.3.X -Helgrind, and did lots of other things. +Julian Seward was the original founder, designer and author of +Valgrind, created the dynamic translation frameworks, wrote Memcheck, +the 3.X versions of Helgrind, Ptrcheck, DHAT, and did lots of other +things. Nicholas Nethercote did the core/tool generalisation, wrote Cachegrind and Massif, and tons of other stuff. @@ -33,8 +34,12 @@ other tweakage. Bart Van Assche wrote and maintains DRD. -Cerion Armour-Brown worked on PowerPC instruction set support in -the Vex dynamic-translation framework. +Cerion Armour-Brown worked on PowerPC instruction set support in the +Vex dynamic-translation framework. Maynard Johnson improved the +Power6 support. + +Kirill Batuzov and Dmitry Zhurikhin did the NEON instruction set +support for ARM. Donna Robinson did the v6 media instruction support. Donna Robinson created and maintains the very excellent http://www.valgrind.org. diff --git a/NEWS b/NEWS index dd3dc21fe2..4682c37c49 100644 --- a/NEWS +++ b/NEWS @@ -13,6 +13,8 @@ Scalability improvements (code cache) Matching Valkyrie support (for Mc, Hg, Pc) Hg annotation improvements More reliable stack unwinding on amd64-linux +Callgrind branch prediction and global bus +Segfaults .w.r.t boost Punted but under consideration for 3.7: Support for code compiled by LLVM-2.8 diff --git a/README b/README index 71c525fddf..2811aee3f5 100644 --- a/README +++ b/README @@ -14,16 +14,17 @@ If you have problems, consult the FAQ to see if there are workarounds. Executive Summary ~~~~~~~~~~~~~~~~~ -Valgrind is an award-winning instrumentation 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. +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 profiler, and -a heap profiler. It also includes two experimental tools: a -heap/stack/global array overrun detector, and a SimPoint basic block vector +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 @@ -35,6 +36,7 @@ platforms: - AMD64/Linux - PPC32/Linux - PPC64/Linux +- ARM/Linux - x86/MacOSX - AMD64/MacOSX @@ -45,6 +47,9 @@ on Intel processors. Also note that the core of MacOSX is called 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 ~~~~~~~~~~~~~ diff --git a/README_DEVELOPERS b/README_DEVELOPERS index e08d872575..9d523db565 100644 --- a/README_DEVELOPERS +++ b/README_DEVELOPERS @@ -101,6 +101,21 @@ without too much problem by following these steps: Steps (1)--(3) can be put in a .gdbinit file, but any directory names must be fully expanded (ie. not an environment variable). +A different and possibly easier way is as follows: + +(1) Run Valgrind as normal, but add the flag --wait-for-gdb=yes. This + puts the tool executable into a wait loop soon after it gains + control. This delays startup for a few seconds. + +(2) In a different shell, do "gdb /proc//exe ", where + you read from the output printed by (1). This attaches + GDB to the tool executable, which should be in the abovementioned + wait loop. + +(3) Do "cont" to continue. After the loop finishes spinning, startup + will continue as normal. Note that comment (3) above re passing + signals applies here too. + Self-hosting ~~~~~~~~~~~~ diff --git a/configure.in b/configure.in index 88a9e1060d..80316aec28 100644 --- a/configure.in +++ b/configure.in @@ -1449,7 +1449,9 @@ AC_TRY_COMPILE([], [ AM_CONDITIONAL([BUILD_LZCNT_TESTS], [test x$ac_have_as_lzcnt = xyes]) - +# XXX JRS 2010 Oct 13: what is this for? For sure, we don't need this +# when building the tool executables. I think we should get rid of it. +# # Check for TLS support in the compiler and linker if test "x${cross_compiling}" = "xno"; then # Native compilation: check whether running a program using TLS succeeds. diff --git a/coregrind/m_main.c b/coregrind/m_main.c index bea5258acf..e5871c42c6 100644 --- a/coregrind/m_main.c +++ b/coregrind/m_main.c @@ -237,7 +237,7 @@ static void usage_NORETURN ( Bool debug_help ) "\n" " %s is %s\n" " Valgrind is Copyright (C) 2000-2010, and GNU GPL'd, by Julian Seward et al.\n" -" LibVEX is Copyright (C) 2004-2010, and GNU GPL'd, by OpenWorks LLP.\n" +" LibVEX is Copyright (C) 2004-2010, and GNU GPL'd, by OpenWorks LLP et al.\n" "\n" " Bug reports, feedback, admiration, abuse, etc, to: %s.\n" "\n"; diff --git a/docs/xml/manual-core-adv.xml b/docs/xml/manual-core-adv.xml index 10929b7ffb..9eea68c3db 100644 --- a/docs/xml/manual-core-adv.xml +++ b/docs/xml/manual-core-adv.xml @@ -55,10 +55,10 @@ use the macros in this file. Also, you are not required to link your program with any extra supporting libraries. The code added to your binary has negligible performance impact: -on x86, amd64, ppc32 and ppc64, the overhead is 6 simple integer instructions -and is probably undetectable except in tight loops. -However, if you really wish to compile out the client requests, you can -compile with (analogous to +on x86, amd64, ppc32, ppc64 and ARM, the overhead is 6 simple integer +instructions and is probably undetectable except in tight loops. +However, if you really wish to compile out the client requests, you +can compile with (analogous to 's effect on assert). @@ -106,7 +106,7 @@ tool-specific macros). Alternatively, for transparent self-modifying-code support, use, or run - on ppc32/Linux or ppc64/Linux. + on ppc32/Linux, ppc64/Linux or ARM/Linux. @@ -567,7 +567,7 @@ functions and merely replaced functions malloc etc safely from within wrappers. -The above comments are true for {x86,amd64,ppc32}-linux. On +The above comments are true for {x86,amd64,ppc32,arm}-linux. On ppc64-linux function wrapping is more fragile due to the (arguably poorly designed) ppc64-linux ABI. This mandates the use of a shadow stack which tracks entries/exits of both wrapper and replacement @@ -578,7 +578,7 @@ finite size, recursion between wrapper/replacement functions is only possible to a limited depth, beyond which Valgrind has to abort the run. This depth is currently 16 calls. -For all platforms ({x86,amd64,ppc32,ppc64}-linux) all the above +For all platforms ({x86,amd64,ppc32,ppc64,arm}-linux) all the above comments apply on a per-thread basis. In other words, wrapping is thread-safe: each thread must individually observe the above restrictions, but there is no need for any kind of inter-thread diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml index 3ca982133a..59eb7878d6 100644 --- a/docs/xml/manual-core.xml +++ b/docs/xml/manual-core.xml @@ -130,11 +130,11 @@ unaffected by optimisation level, and for profiling tools like Cachegrind it is better to compile your program at its normal optimisation level. Valgrind understands both the older "stabs" debugging format, used -by GCC versions prior to 3.1, and the newer DWARF2 and DWARF3 formats +by GCC versions prior to 3.1, and the newer DWARF2/3/4 formats used by GCC 3.1 and later. We continue to develop our debug-info readers, although the majority of effort will naturally enough go into the newer -DWARF2/3 reader. +DWARF readers. When you're ready to roll, run Valgrind as described above. Note that you should run the real @@ -1235,7 +1235,7 @@ that can report errors, e.g. Memcheck, but not Cachegrind. Be careful when using , since it will cause pre-existing .dSYM - directories to be silently deleted and re-created. Also note the + directories to be silently deleted and re-created. Also note that dsymutil is quite slow, sometimes excessively so. @@ -1390,13 +1390,13 @@ need to use these. will likely lead to incorrect behaviour and/or crashes. Valgrind has three levels of self-modifying code detection: - no detection, detect self-modifying code on the stack (which used by + no detection, detect self-modifying code on the stack (which is used by GCC to implement nested functions), or detect self-modifying code everywhere. Note that the default option will catch the vast majority of cases. The main case it will not catch is programs such as JIT compilers that dynamically generate code and subsequently overwrite part or all of it. Running with - all will slow Valgrind down greatly. Running with + all will slow Valgrind down noticeably. Running with none will rarely speed things up, since very little code gets put on the stack for most programs. The VALGRIND_DISCARD_TRANSLATIONS client request is @@ -1408,11 +1408,11 @@ need to use these. --> - Some architectures (including ppc32 and ppc64) require + Some architectures (including ppc32, ppc64 and ARM) require programs which create code at runtime to flush the instruction cache in between code generation and first use. Valgrind - observes and honours such instructions. Hence, on ppc32/Linux - and ppc64/Linux, Valgrind always provides complete, transparent + observes and honours such instructions. Hence, on ppc32/Linux, + ppc64/Linux and ARM/Linux, Valgrind always provides complete, transparent support for self-modifying code. It is only on platforms such as x86/Linux, AMD64/Linux and x86/Darwin that you need to use this option. @@ -1711,8 +1711,7 @@ tools Helgrind and/or DRD to track them down. futex and so on. clone is supported where either everything is shared (a thread) or nothing is shared (fork-like); partial -sharing will fail. Again, any use of atomic instruction sequences in shared -memory between processes will not work reliably. +sharing will fail. @@ -1756,16 +1755,15 @@ will create a core dump in the usual way. We use the standard Unix ./configure, make, make -install mechanism, and we have attempted to -ensure that it works on machines with kernel 2.4 or 2.6 and glibc -2.2.X to 2.10.X. Once you have completed +install mechanism. Once you have completed make install you may then want to run the regression tests with make regtest. -There are five options (in addition to the usual - which affect how Valgrind is built: +In addition to the usual +, there are three + options which affect how Valgrind is built: @@ -1777,25 +1775,17 @@ with make regtest. - - - TLS (Thread Local Storage) is a relatively new mechanism which - requires compiler, linker and kernel support. Valgrind tries to - automatically test if TLS is supported and if so enables this option. - Sometimes it cannot test for TLS, so this option allows you to - override the automatic test. - - - On 64-bit - platforms (amd64-linux, ppc64-linux), Valgrind is by default built - in such a way that both 32-bit and 64-bit executables can be run. - Sometimes this cleverness is a problem for a variety of reasons. - These two options allow for single-target builds in this situation. - If you issue both, the configure script will complain. Note they - are ignored on 32-bit-only platforms (x86-linux, ppc32-linux). + On 64-bit platforms (amd64-linux, ppc64-linux, + amd64-darwin), Valgrind is by default built in such a way that + both 32-bit and 64-bit executables can be run. Sometimes this + cleverness is a problem for a variety of reasons. These two + options allow for single-target builds in this situation. If you + issue both, the configure script will complain. Note they are + ignored on 32-bit-only platforms (x86-linux, ppc32-linux, + arm-linux, x86-darwin). @@ -1859,29 +1849,45 @@ subject to the following constraints: - On x86 and amd64, there is no support for 3DNow! instructions. - If the translator encounters these, Valgrind will generate a SIGILL - when the instruction is executed. Apart from that, on x86 and amd64, - essentially all instructions are supported, up to and including SSSE3. + On x86 and amd64, there is no support for 3DNow! + instructions. If the translator encounters these, Valgrind will + generate a SIGILL when the instruction is executed. Apart from + that, on x86 and amd64, essentially all instructions are supported, + up to and including SSE4.2 in 64-bit mode and SSSE3 in 32-bit mode. + Some exceptions: SSE4.2 AES instructions are not supported in + 64-bit mode, and 32-bit mode does in fact support the bare minimum + SSE4 instructions to needed to run programs on MacOSX 10.6 on + 32-bit targets. - On ppc32 and ppc64, almost all integer, floating point and Altivec - instructions are supported. Specifically: integer and FP insns that are - mandatory for PowerPC, the "General-purpose optional" group (fsqrt, fsqrts, - stfiwx), the "Graphics optional" group (fre, fres, frsqrte, frsqrtes), and - the Altivec (also known as VMX) SIMD instruction set, are supported. + On ppc32 and ppc64, almost all integer, floating point and + Altivec instructions are supported. Specifically: integer and FP + insns that are mandatory for PowerPC, the "General-purpose + optional" group (fsqrt, fsqrts, stfiwx), the "Graphics optional" + group (fre, fres, frsqrte, frsqrtes), and the Altivec (also known + as VMX) SIMD instruction set, are supported. Also, instructions + from the Power ISA 2.05 specification, as present in POWER6 CPUs, + are supported. + + + + On ARM, essentially the entire ARMv7-A instruction set + is supported, in both ARM and Thumb mode. ThumbEE and Jazelle are + not supported. NEON and VFPv3 support is fairly complete. ARMv6 + media instruction support is mostly done but not yet complete. + If your program does its own memory management, rather than using malloc/new/free/delete, it should still work, but Memcheck's - error checking won't be so effective. If you describe your program's - memory management scheme using "client requests" - (see ), Memcheck can do - better. Nevertheless, using malloc/new and free/delete is still the - best approach. + error checking won't be so effective. If you describe your + program's memory management scheme using "client requests" (see + ), Memcheck can do + better. Nevertheless, using malloc/new and free/delete is still + the best approach. @@ -1902,25 +1908,32 @@ subject to the following constraints: - Memory consumption of your program is majorly increased whilst - running under Valgrind. This is due to the large amount of - administrative information maintained behind the scenes. Another - cause is that Valgrind dynamically translates the original - executable. Translated, instrumented code is 12-18 times larger than - the original so you can easily end up with 50+ MB of translations - when running (eg) a web browser. + Memory consumption of your program is majorly increased + whilst running under Valgrind's Memcheck tool. This is due to the + large amount of administrative information maintained behind the + scenes. Another cause is that Valgrind dynamically translates the + original executable. Translated, instrumented code is 12-18 times + larger than the original so you can easily end up with 100+ MB of + translations when running (eg) a web browser. Valgrind can handle dynamically-generated code just fine. If - you regenerate code over the top of old code (ie. at the same memory - addresses), if the code is on the stack Valgrind will realise the - code has changed, and work correctly. This is necessary to handle - the trampolines GCC uses to implemented nested functions. If you - regenerate code somewhere other than the stack, you will need to use - the option, and Valgrind will run more - slowly than normal. Or you can add client requests that tell Valgrind - when your program has overwritten code. + you regenerate code over the top of old code (ie. at the same + memory addresses), if the code is on the stack Valgrind will + realise the code has changed, and work correctly. This is + necessary to handle the trampolines GCC uses to implemented nested + functions. If you regenerate code somewhere other than the stack, + and you are running on an 32- or 64-bit x86 CPU, you will need to + use the option, and Valgrind will + run more slowly than normal. Or you can add client requests that + tell Valgrind when your program has overwritten code. + + On other platforms (ARM, PowerPC) Valgrind observes and + honours the cache invalidation hints that programs are obliged to + emit to notify new code, and so self-modifying-code support should + work automatically, without the need + for . @@ -1996,6 +2009,19 @@ subject to the following constraints: warn about, attempts to enable either mode. + + Valgrind has the following limitations in + its implementation of ARM VFPv3 arithmetic, relative to + IEEE754. + + Essentially the same: no exceptions, and limited observance + of rounding mode. Also, switching the VFP unit into vector mode + will cause Valgrind to abort the program -- it has no way to + emulate vector uses of VFP at a reasonable performance level. This + is no big deal given that non-scalar uses of VFP instructions are + in any case deprecated. + + Valgrind has the following limitations in its implementation of PPC32 and PPC64 floating point diff --git a/docs/xml/manual-intro.xml b/docs/xml/manual-intro.xml index 452effd360..3efbdeea94 100644 --- a/docs/xml/manual-intro.xml +++ b/docs/xml/manual-intro.xml @@ -53,6 +53,12 @@ and without disturbing the existing structure. make your programs use less memory. + + DHAT is a different kind of heap + profiler. It helps you understand issues of block lifetimes, + block utilisation, and layout inefficiencies. + + Ptrcheck is an experimental heap, stack and global array overrun detector. Its functionality overlaps somewhat diff --git a/docs/xml/quick-start-guide.xml b/docs/xml/quick-start-guide.xml index 306c90866d..f7bbf68741 100644 --- a/docs/xml/quick-start-guide.xml +++ b/docs/xml/quick-start-guide.xml @@ -48,7 +48,8 @@ numbers. Using is also a good idea, if you can tolerate the slowdown. With line numbers in error messages can be inaccurate, although generally speaking running Memcheck on code compiled -at works fairly well. +at works fairly well, and the speed improvement +compared to running is quite significant. Use of and above is not recommended as Memcheck occasionally reports uninitialised-value errors which don't diff --git a/docs/xml/vg-entities.xml b/docs/xml/vg-entities.xml index bc6ea16cbc..19a68e9f44 100644 --- a/docs/xml/vg-entities.xml +++ b/docs/xml/vg-entities.xml @@ -2,12 +2,12 @@ - + - - + + diff --git a/massif/docs/ms-manual.xml b/massif/docs/ms-manual.xml index 9e318c51f8..51f872b95e 100644 --- a/massif/docs/ms-manual.xml +++ b/massif/docs/ms-manual.xml @@ -688,6 +688,17 @@ in a particular column, which makes following the allocation chains easier. + + + + + + Tells Massif to profile memory at the page level rather + than at the malloc'd block level. See above for details. + + + + diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml index 4c75629d1f..c380fce2b3 100644 --- a/memcheck/docs/mc-manual.xml +++ b/memcheck/docs/mc-manual.xml @@ -763,7 +763,7 @@ criteria: - + When the client program releases memory using @@ -779,7 +779,7 @@ criteria: have been freed. This option specifies the maximum total size, in bytes, of the - blocks in the queue. The default value is ten million bytes. + blocks in the queue. The default value is twenty million bytes. Increasing this increases the total amount of memory used by Memcheck but may detect invalid uses of freed blocks which would otherwise go undetected. @@ -1153,8 +1153,8 @@ follows: Each byte in memory has 8 associated V (valid-value) bits, saying whether or not the byte has a defined value, and a single A (valid-address) bit, saying whether or not the program currently has - the right to read/write that address. (But, as mentioned above, heavy - use of compression means the overhead is typically less than 25%.) + the right to read/write that address. As mentioned above, heavy + use of compression means the overhead is typically around 25%. diff --git a/none/tests/cmdline1.stdout.exp b/none/tests/cmdline1.stdout.exp index 7306e7587b..9c6d5feb73 100644 --- a/none/tests/cmdline1.stdout.exp +++ b/none/tests/cmdline1.stdout.exp @@ -74,7 +74,7 @@ usage: valgrind [options] prog-and-args Nulgrind is Copyright (C) 2002-2010, and GNU GPL'd, by Nicholas Nethercote. Valgrind is Copyright (C) 2000-2010, and GNU GPL'd, by Julian Seward et al. - LibVEX is Copyright (C) 2004-2010, and GNU GPL'd, by OpenWorks LLP. + LibVEX is Copyright (C) 2004-2010, and GNU GPL'd, by OpenWorks LLP et al. Bug reports, feedback, admiration, abuse, etc, to: www.valgrind.org. diff --git a/none/tests/cmdline2.stdout.exp b/none/tests/cmdline2.stdout.exp index 0d39df8114..d27316f1a9 100644 --- a/none/tests/cmdline2.stdout.exp +++ b/none/tests/cmdline2.stdout.exp @@ -125,7 +125,7 @@ usage: valgrind [options] prog-and-args Nulgrind is Copyright (C) 2002-2010, and GNU GPL'd, by Nicholas Nethercote. Valgrind is Copyright (C) 2000-2010, and GNU GPL'd, by Julian Seward et al. - LibVEX is Copyright (C) 2004-2010, and GNU GPL'd, by OpenWorks LLP. + LibVEX is Copyright (C) 2004-2010, and GNU GPL'd, by OpenWorks LLP et al. Bug reports, feedback, admiration, abuse, etc, to: www.valgrind.org.