From: Nicholas Nethercote Date: Mon, 15 Aug 2005 04:26:13 +0000 (+0000) Subject: A few minor manual updates. X-Git-Tag: svn/VALGRIND_3_1_0~599 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b329702e3b60981bfa9399c8e5a11ba40ead324a;p=thirdparty%2Fvalgrind.git A few minor manual updates. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4419 --- diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml index ba0ea3c90c..4f0a56b5e8 100644 --- a/memcheck/docs/mc-manual.xml +++ b/memcheck/docs/mc-manual.xml @@ -427,8 +427,8 @@ precisely reflect any changes in memory permissions caused by the system call. Here's an example of two system calls with invalid parameters: - #include <unistd.h> + #include + #include int main( void ) { char* arr = malloc(10); @@ -510,8 +510,8 @@ don't make any assumptions about the language implementation. - -Writing suppressions files + +Writing suppression files The basic suppression format is described in . @@ -564,7 +564,7 @@ Memcheck,Addrcheck:suppression_type]]> - Overlap, meaning a + Or: Overlap, meaning a src / dst overlap in memcpy() or a similar @@ -572,9 +572,8 @@ Memcheck,Addrcheck:suppression_type]]> - Last but not least, you can suppress leak reports with - Leak. Leak suppression was - added in valgrind-1.9.3, I believe. + Or: Leak, meaning + a memory leak. @@ -612,7 +611,7 @@ what and how Memcheck is checking. Valid-value (V) bits It is simplest to think of Memcheck implementing a -synthetic Intel x86 CPU which is identical to a real CPU, except +synthetic CPU which is identical to a real CPU, except for one crucial detail. Every bit (literally) of data processed, stored and handled by the real CPU has, in the synthetic CPU, an associated "valid-value" bit, which says whether or not the @@ -631,8 +630,8 @@ bitmap. In short, each bit in the system has an associated V bit, which follows it around everywhere, even inside the CPU. Yes, -the CPU's (integer and %eflags) -registers have their own V bit vectors. +all the CPU's registers (integer, floating point, and condition +registers) have their own V bit vectors. Copying values around does not cause Memcheck to check for, or report on, errors. However, when a value is used in a way @@ -673,14 +672,14 @@ the printf -- an observable action of your program -- that Memcheck complains. Most low level operations, such as adds, cause Memcheck to -use the V bits for the operands to calculate -the V bits for the result. Even if the result is partially or -wholly undefined, it does not complain. - -Checks on definedness only occur in two places: when a -value is used to generate a memory address, and where control -flow decision needs to be made. Also, when a system call is -detected, valgrind checks definedness of parameters as +use the V bits for the operands to calculate the V bits for the result. +Even if the result is partially or wholly undefined, it does not +complain. + +Checks on definedness only occur in three places: when a +value is used to generate a memory address, when control +flow decision needs to be made, and when a system call is +detected, Valgrind checks definedness of parameters as required. If a check should detect undefinedness, an error message is @@ -729,20 +728,6 @@ necessary. This allows gcc to copy warning will only be emitted if the uninitialised values are later used. -One final twist to this story. The above scheme allows -garbage to pass through the CPU's integer registers without -complaint. It does this by giving the integer registers -V tags, passing these around in the expected -way. This complicated and computationally expensive to do, but -is necessary. Memcheck is more simplistic about floating-point -loads and stores. In particular, V bits for -data read as a result of floating-point loads are checked at the -load instruction. So if your program uses the floating-point -registers to do memory-to-memory copies, you will get complaints -about uninitialised values. Fortunately, I have not yet -encountered a program which (ab)uses the floating-point registers -in this way. - @@ -756,23 +741,22 @@ access any particular memory location. We now consider the latter issue. As described above, every bit in memory or in the CPU has -an associated valid-value (V) bit. In +an associated valid-value (V) bit. In addition, all bytes in memory, but not in the CPU, have an -associated valid-address (A) bit. This +associated valid-address (A) bit. This indicates whether or not the program can legitimately read or write that location. It does not give any indication of the validity or the data at that location -- that's the job of the -V bits -- only whether or not the location may +V bits -- only whether or not the location may be accessed. Every time your program reads or writes memory, Memcheck -checks the A bits associated with the address. +checks the A bits associated with the address. If any of them indicate an invalid address, an error is emitted. Note that the reads and writes themselves do not change the A bits, only consult them. -So how do the A bits get set/cleared? -Like this: +So how do the A bits get set/cleared? Like this: @@ -788,15 +772,14 @@ Like this: - When the stack pointer register - (%esp) moves up or down, + (SP) moves up or down, A bits are set. The rule is that the area - from %esp up to the base of the stack is - marked as accessible, and below %esp is + from SP up to the base of the stack is + marked as accessible, and below SP is inaccessible. (If that sounds illogical, bear in mind that the stack grows down, not up, on almost all Unix systems, - including GNU/Linux.) Tracking %esp like + including GNU/Linux.) Tracking SP like this has the useful side-effect that the section of stack used by a function for local variables etc is automatically marked accessible on function entry and inaccessible on @@ -830,66 +813,49 @@ follows: Each byte in memory has 8 associated - V (valid-value) bits, saying whether or + V (valid-value) bits, saying whether or not the byte has a defined value, and a single - A (valid-address) bit, saying whether or + A (valid-address) bit, saying whether or not the program currently has the right to read/write that address. When memory is read or written, the relevant - A bits are consulted. If they indicate an + A bits are consulted. If they indicate an invalid address, Valgrind emits an Invalid read or Invalid write error. - When memory is read into the CPU's integer registers, - the relevant V bits are fetched from + When memory is read into the CPU's registers, + the relevant V bits are fetched from memory and stored in the simulated CPU. They are not consulted. - When an integer register is written out to memory, the - V bits for that register are written back + When a register is written out to memory, the + V bits for that register are written back to memory too. - When memory is read into the CPU's floating point - registers, the relevant V bits are read - from memory and they are immediately checked. If any are - invalid, an uninitialised value error is emitted. This - precludes using the floating-point registers to copy - possibly-uninitialised memory, but simplifies Valgrind in - that it does not have to track the validity status of the - floating-point registers. - - - - As a result, when a floating-point register is written - to memory, the associated V bits are set to indicate a valid - value. - - - - When values in integer CPU registers are used to + When values in CPU registers are used to generate a memory address, or to determine the outcome of a - conditional branch, the V bits for those + conditional branch, the V bits for those values are checked, and an error emitted if any of them are undefined. - When values in integer CPU registers are used for any + When values in CPU registers are used for any other purpose, Valgrind computes the V bits for the result, but does not check them. - One the V bits for a value in the + One the V bits for a value in the CPU have been checked, they are then set to indicate validity. This avoids long chains of errors.