From: Julian Seward Date: Sat, 17 Nov 2007 09:43:25 +0000 (+0000) Subject: Spelling fixes and misc tidying for the manual. (Brian Gough) X-Git-Tag: svn/VALGRIND_3_3_0~118 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5e2a8da202ec0d2364e2604a7689703724dce210;p=thirdparty%2Fvalgrind.git Spelling fixes and misc tidying for the manual. (Brian Gough) git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7173 --- diff --git a/callgrind/docs/cl-format.xml b/callgrind/docs/cl-format.xml index b80b1a92db..f997aa8e44 100644 --- a/callgrind/docs/cl-format.xml +++ b/callgrind/docs/cl-format.xml @@ -73,7 +73,7 @@ number. Thus, the first cost line specifies that in line 15 of source file "file.f" there is code belonging to function "main". While running, 90 CPU cycles passed by, and 2 of the 14 instructions executed were floating point -operations. Similarily, the next line specifies that there were 12 instructions +operations. Similarly, the next line specifies that there were 12 instructions executed in the context of function "main" which can be related to line 16 in file "file.f", taking 20 CPU cycles. If a cost line specifies less event counts than given in the "events" line, the rest is assumed to be zero. I.e., there @@ -93,8 +93,8 @@ called: profile data only contains sums. The most important extension to the original format of Cachegrind is the ability to specify call relationship among functions. More generally, you -specify assoziations among positions. For this, the second part of the -file also can contain assoziation specifications. These look similar to +specify associations among positions. For this, the second part of the +file also can contain association specifications. These look similar to position specifications, but consist of 2 lines. For calls, the format looks like @@ -109,7 +109,7 @@ called function, and a "cfl=" specification if the function is in another source file. The 2nd line looks like a regular cost line with the difference that inclusive cost spent inside of the function call has to be specified. -Other assoziations which or for example (conditional) jumps. See the +Other associations which or for example (conditional) jumps. See the reference below for details. @@ -198,7 +198,7 @@ fl=(2) fn=(3) 20 700 -As position specifications carry no information themself, but only change +As position specifications carry no information themselves, but only change the meaning of subsequent cost lines or associations, they can appear everywhere in the file without any negative consequence. Especially, you can define name compression mappings directly after the header, and before any cost @@ -225,7 +225,7 @@ fn=(1) Subposition Compression If a Callgrind data file should hold costs for each assembler instruction -of a program, you specify subpostion "instr" in the "positions:" header line, +of a program, you specify subposition "instr" in the "positions:" header line, and each cost line has to include the address of some instruction. Addresses are allowed to have a size of 64bit to support 64bit architectures. Thus, repeating similar, long addresses for almost every line in the data file can @@ -239,7 +239,7 @@ also for line numbers; both addresses and line numbers are called "subpositions" of the last cost line, and starts with a "+" to specify a positive difference, a "-" to specify a negative difference, or consists of "*" to specify the same subposition. Because absolute subpositions always are positive (ie. never -prefixed by "-"), any relative specification is non-ambigous; additionally, +prefixed by "-"), any relative specification is non-ambiguous; additionally, absolute and relative subposition specifications can be mixed freely. Assume the following example (subpositions can always be specified as hexadecimal numbers, beginning with "0x"): @@ -292,7 +292,7 @@ Fetches", this can be specified the header line event: Ir : Instruction Fetches events: Ir Dr -In this example, "Dr" itself has no long name assoziated. The order of +In this example, "Dr" itself has no long name associated. The order of "event:" lines and the "events:" line is of no importance. Additionally, inherited event types can be introduced for which no raw data is available, but which are calculated from given types. Suppose the last example, you could add @@ -339,7 +339,7 @@ for "Ir and "Dr". | ('#' NoNewLineChar*) | CostLine | PositionSpecification - | AssoziationSpecification + | AssociationSpecification CostLine := SubPositionList Costs? SubPositionList := (SubPosition+ Space+)+ SubPosition := Number | "+" Number | "-" Number | "*" @@ -349,7 +349,7 @@ for "Ir and "Dr". CostPosition := "ob" | "fl" | "fi" | "fe" | "fn" CalledPosition := " "cob" | "cfl" | "cfn" PositionName := ( "(" Number ")" )? (Space* NoNewLineChar* )? -AssoziationSpecification := CallSpezification +AssociationSpecification := CallSpecification | JumpSpecification CallSpecification := CallLine "\n" CostLine CallLine := "calls=" Space* Number Space+ SubPositionList @@ -433,7 +433,7 @@ for "Ir and "Dr". - events: event type abbrevations [Cachegrind] + events: event type abbreviations [Cachegrind] A list of short names of the event types logged in this file. The order is the same as in cost lines. The first event type is the second or third number in a cost line, depending on the value of diff --git a/callgrind/docs/cl-manual.xml b/callgrind/docs/cl-manual.xml index b33d027bd5..312c6271dc 100644 --- a/callgrind/docs/cl-manual.xml +++ b/callgrind/docs/cl-manual.xml @@ -283,7 +283,7 @@ callgrind.out.pid.part-threa and . To zero cost counters before entering a function, use . - The prefix method for specifying function names was choosen to + The prefix method for specifying function names was chosen to ease the use with C++: you don't have to specify full signatures. You can specify these options multiple times for different function prefixes. @@ -412,10 +412,10 @@ callgrind.out.pid.part-threa cut off uninteresting areas. Despite the meaningless of inclusive costs in cycles, the big - drawback for visualization motivates the possibility to temporarely + drawback for visualization motivates the possibility to temporarily switch off cycle detection in KCachegrind, which can lead to misguiding visualization. However, often cycles appear because of - unlucky superposition of independant call chains in a way that + unlucky superposition of independent call chains in a way that the profile result will see a cycle. Neglecting uninteresting calls with very small measured inclusive cost would break these cycles. In such cases, incorrect handling of cycles by not detecting @@ -436,7 +436,7 @@ callgrind.out.pid.part-threa symbol explosion. The latter imposes large memory requirement for Callgrind with possible out-of-memory conditions, and big profile data files. - A further possibility to avoid cycles in Callgrinds profile data + A further possibility to avoid cycles in Callgrind's profile data output is to simply leave out given functions in the call graph. Of course, this also skips any call information from and to an ignored function, and thus can break a cycle. Candidates for this typically are dispatcher functions in event @@ -619,7 +619,7 @@ be executed. For interactive control use Dump profile data every <count> basic blocks. - Whether a dump is needed is only checked when Valgrinds internal + Whether a dump is needed is only checked when Valgrind's internal scheduler is run. Therefore, the minimum setting useful is about 100000. The count is a 64-bit value to make long dump periods possible. diff --git a/docs/xml/FAQ.xml b/docs/xml/FAQ.xml index be3e111ef4..0dbf6e98a4 100644 --- a/docs/xml/FAQ.xml +++ b/docs/xml/FAQ.xml @@ -193,7 +193,7 @@ collect2: ld returned 1 exit status much more slowly, but should detect the use of the out-of-date code. - Alternativaly, if you have the source code to the JIT compiler + Alternatively, if you have the source code to the JIT compiler you can insert calls to the VALGRIND_DISCARD_TRANSLATIONS client request to mark out-of-date code, saving you from using @@ -555,7 +555,7 @@ int main(void) As for eager reporting of copies of uninitialised memory values, this has been suggested multiple times. Unfortunately, almost all - programs legitimately copy uninitialise memory values around (because + programs legitimately copy uninitialised memory values around (because compilers pad structs to preserve alignment) and eager checking leads to hundreds of false positives. Therefore Memcheck does not support eager checking at this time. diff --git a/docs/xml/manual-core.xml b/docs/xml/manual-core.xml index 2e061ae2ae..addb2bdd20 100644 --- a/docs/xml/manual-core.xml +++ b/docs/xml/manual-core.xml @@ -113,7 +113,7 @@ uninitialised value errors, or missing uninitialised value errors. We have looked in detail into fixing this, and unfortunately the result is that doing so would give a further significant slowdown in what is already a slow tool. So the best solution is to turn off optimisation altogether. Since -this often makes things unmanagably slow, a reasonable compromise is to use +this often makes things unmanageably slow, a reasonable compromise is to use -O. This gets you the majority of the benefits of higher optimisation levels whilst keeping relatively small the chances of false positives or false negatives from Memcheck. Also, you @@ -422,7 +422,7 @@ distribution, provides some good examples. Second line: name of the tool(s) that the suppression is for (if more than one, comma-separated), and the name of the suppression - itself, separated by a colon (Nb: no spaces are allowed), eg: + itself, separated by a colon (n.b.: no spaces are allowed), eg: @@ -530,7 +530,7 @@ freely mix obj: and As mentioned above, Valgrind's core accepts a common set of flags. The tools also accept tool-specific flags, which are documented -seperately for each tool. +separately for each tool. You invoke Valgrind like this: @@ -732,7 +732,7 @@ categories. causes the log file name to be qualified using the contents of the environment variable $VAR. This is useful when running MPI programs. For further details, see - Section 2.3 "The Commentary" + the commentary in the manual. @@ -751,7 +751,7 @@ categories. be used in conjunction with the valgrind-listener program. For further details, see - Section 2.3 "The Commentary" + the commentary in the manual. @@ -890,7 +890,7 @@ that can report errors, e.g. Memcheck, but not Cachegrind. - + @@ -1096,7 +1096,7 @@ need to use these. The GNU C library (libc.so), which is used by all programs, may allocate memory for its own uses. Usually it doesn't bother to free that memory when the program - ends - there would be no point, since the Linux kernel reclaims + ends—there would be no point, since the Linux kernel reclaims all process resources when a process exits anyway, so it would just slow things down. @@ -1418,7 +1418,7 @@ tool-specific macros). VALGRIND_DESTROY_MEMPOOL: This should be used in conjunction with - VALGRIND_CREATE_MEMPOOL + VALGRIND_CREATE_MEMPOOL. Again, see the comments in valgrind.h for information on how to use it. @@ -1428,7 +1428,7 @@ tool-specific macros). VALGRIND_MEMPOOL_ALLOC: This should be used in conjunction with - VALGRIND_CREATE_MEMPOOL + VALGRIND_CREATE_MEMPOOL. Again, see the comments in valgrind.h for information on how to use it. @@ -1438,7 +1438,7 @@ tool-specific macros). VALGRIND_MEMPOOL_FREE: This should be used in conjunction with - VALGRIND_CREATE_MEMPOOL + VALGRIND_CREATE_MEMPOOL. Again, see the comments in valgrind.h for information on how to use it. @@ -1505,8 +1505,8 @@ tool-specific macros). VALGRIND_STACK_CHANGE(id, start, end): Changes a previously registered stack. Informs - Valgrind that the previously registerer stack with stack id - id has changed it's start and end + Valgrind that the previously registered stack with stack id + id has changed its start and end values. Use this if your user-level thread package implements stack growth. @@ -1548,7 +1548,7 @@ concurrency, critical race, locking, or similar, bugs. Your program will use the native libpthread, but not all of its facilities -will work. In particular, synchonisation of processes via shared-memory +will work. In particular, synchronisation of processes via shared-memory segments will not work. This relies on special atomic instruction sequences which Valgrind does not emulate in a way which works between processes. Unfortunately there's no way for Valgrind to warn when this is happening, @@ -1599,7 +1599,7 @@ will create a core dump in the usual way. Function wrapping -Valgrind versions 3.2.0 and above and can do function wrapping on all +Valgrind versions 3.2.0 and above can do function wrapping on all supported targets. In function wrapping, calls to some specified function are intercepted and rerouted to a different, user-supplied function. This can do whatever it likes, typically examining the @@ -2197,7 +2197,7 @@ following constraints: programs behave as if they had been run on a machine with 64-bit IEEE floats, for example PowerPC. On amd64 FP arithmetic is done by default on SSE2, so amd64 looks more like PowerPC than x86 from an FP - perspective, and there are far fewer noticable accuracy differences + perspective, and there are far fewer noticeable accuracy differences than with x86. Rounding: Valgrind does observe the 4 IEEE-mandated rounding @@ -2212,7 +2212,7 @@ following constraints: negative number, etc), division by zero, overflow, underflow, inexact (loss of precision). - For each exception, two courses of action are defined by 754: + For each exception, two courses of action are defined by IEEE754: either (1) a user-defined exception handler may be called, or (2) a default action is defined, which "fixes things up" and allows the computation to proceed without throwing an exception. diff --git a/docs/xml/manual-intro.xml b/docs/xml/manual-intro.xml index a4b1b84f43..7a4152d0eb 100644 --- a/docs/xml/manual-intro.xml +++ b/docs/xml/manual-intro.xml @@ -153,7 +153,7 @@ and profiling. This manual is structured similarly. it supports. Then, each tool has its own chapter in this manual. You only need to read the documentation for the core and for the tool(s) you actually use, although you may find it helpful to be at least a little -bit familar with what all tools do. If you're new to all this, you probably +bit familiar with what all tools do. If you're new to all this, you probably want to run the Memcheck tool. The final chapter explains how to write a new tool. diff --git a/docs/xml/valgrind-manpage.xml b/docs/xml/valgrind-manpage.xml index ffe33646a1..4bf9bb7b04 100644 --- a/docs/xml/valgrind-manpage.xml +++ b/docs/xml/valgrind-manpage.xml @@ -79,7 +79,7 @@ leaks. adds call graph tracing to cachegrind. It can be used to get call counts and inclusive cost for each call happening in your - program. In addition to cachegrind, callgrind can annotate threads separatly, + program. In addition to cachegrind, callgrind can annotate threads separately, and every instruction of disassembler output of your program with the number of instructions executed and cache misses incurred. diff --git a/helgrind/docs/hg-manual.xml b/helgrind/docs/hg-manual.xml index 73dde8c69d..4197fa41be 100644 --- a/helgrind/docs/hg-manual.xml +++ b/helgrind/docs/hg-manual.xml @@ -1,6 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[ %vg-entities; ]> @@ -320,7 +321,7 @@ sections below explain them. Here we merely note their presence: points of these two threads, so you can see which threads it is referring to. - Helgrind tries to provide an explaination of why the + Helgrind tries to provide an explanation of why the race exists: "Location 0x601034 has never been protected by any lock". @@ -878,7 +879,7 @@ of false data-race errors. Make sure your application, and all the libraries it uses, use the POSIX threading primitives. Helgrind needs to be able to see all events pertaining to thread creation, exit, locking and - other syncronisation events. To do so it intercepts many POSIX + other synchronisation events. To do so it intercepts many POSIX pthread_ functions. Do not roll your own threading primitives (mutexes, etc) diff --git a/massif/docs/ms-manual.xml b/massif/docs/ms-manual.xml index 42d41722bf..c5ae307670 100644 --- a/massif/docs/ms-manual.xml +++ b/massif/docs/ms-manual.xml @@ -1,6 +1,7 @@ + "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" +[ %vg-entities; ]> diff --git a/memcheck/docs/mc-manual.xml b/memcheck/docs/mc-manual.xml index ac7f7d5fc7..b8c36a7ce9 100644 --- a/memcheck/docs/mc-manual.xml +++ b/memcheck/docs/mc-manual.xml @@ -167,7 +167,7 @@ the following problems: Controls how memcheck handles word-sized, word-aligned loads from addresses for which some bytes are - addressible and others are not. When yes, such + addressable and others are not. When yes, such loads do not produce an address error. Instead, loaded bytes originating from illegal addresses are marked as uninitialised, and those corresponding to legal addresses are handled in the normal @@ -418,12 +418,12 @@ permissions Also, if a system call needs to read from a buffer provided by - your program, Memcheck checks that the entire buffer is addressible + your program, Memcheck checks that the entire buffer is addressable and has valid data, ie, it is readable. Also, if the system call needs to write to a user-supplied - buffer, Memcheck checks that the buffer is addressible. + buffer, Memcheck checks that the buffer is addressable. @@ -937,7 +937,7 @@ follows: This apparently strange choice reduces the amount of confusing information presented to the user. It avoids the unpleasant phenomenon in which memory is read from a place which is both - unaddressible and contains invalid values, and, as a result, you get + unaddressable and contains invalid values, and, as a result, you get not only an invalid-address (read/write) error, but also a potentially large set of uninitialised-value errors, one for every time the value is used. @@ -958,24 +958,24 @@ is: - malloc/new/new[]: the returned memory is marked as addressible + malloc/new/new[]: the returned memory is marked as addressable but not having valid values. This means you have to write to it before you can read it. - calloc: returned memory is marked both addressible and valid, + calloc: returned memory is marked both addressable and valid, since calloc clears the area to zero. realloc: if the new size is larger than the old, the new - section is addressible but invalid, as with malloc. + section is addressable but invalid, as with malloc. If the new size is smaller, the dropped-off section is marked - as unaddressible. You may only pass to realloc a pointer previously + as unaddressable. You may only pass to realloc a pointer previously issued to you by malloc/calloc/realloc. @@ -983,7 +983,7 @@ is: free/delete/delete[]: you may only pass to these functions a pointer previously issued to you by the corresponding allocation function. Otherwise, Memcheck complains. If the pointer is indeed - valid, Memcheck marks the entire area it points at as unaddressible, + valid, Memcheck marks the entire area it points at as unaddressable, and places the block in the freed-blocks-queue. The aim is to defer as long as possible reallocation of this block. Until that happens, all attempts to access it will elicit an invalid-address error, as diff --git a/memcheck/docs/mc-tech-docs.xml b/memcheck/docs/mc-tech-docs.xml index cebe613262..33146cecf7 100644 --- a/memcheck/docs/mc-tech-docs.xml +++ b/memcheck/docs/mc-tech-docs.xml @@ -708,7 +708,7 @@ follows: do stores and loads of V bits to/from the sparse array which keeps track of V bits in memory, and VGM_(handle_esp_assignment), - which messes with memory addressibility resulting from + which messes with memory addressability resulting from changes in %ESP. @@ -1185,7 +1185,7 @@ express the instrumentation. The former group contains: LEA1 and LEA2 are not strictly - necessary, but allow faciliate better translations. They + necessary, but facilitate better translations. They record the fancy x86 addressing modes in a direct way, which allows those amodes to be emitted back into the final instruction stream more or less verbatim. @@ -1302,7 +1302,7 @@ uopcodes are as follows: from the synthesised shadow memory that Valgrind maintains. In fact they do more than that, since they also do address-validity checks, and emit complaints if the - read/written addresses are unaddressible. + read/written addresses are unaddressable. @@ -1716,7 +1716,7 @@ transformations are done: because it is vital the instrumenter always has an up-to-date %ESP value available, %ESP changes affect - addressibility of the memory around the simulated stack + addressability of the memory around the simulated stack pointer. The implication of the above paragraph is that the @@ -2594,9 +2594,9 @@ if elements are used before they get new values. VALGRIND_MAKE_READABLE(addr, len)]]> and also, to check that memory is -addressible/initialised, +addressable/initialised, I then include in my sources a header defining these @@ -2691,7 +2691,7 @@ the error. run it on post-CPP'd C/C++ source. The parser/prettyprinter is probably not as hard as it sounds; I would write it in Haskell, a powerful functional language well suited to doing symbolic - computation, with which I am intimately familar. There is + computation, with which I am intimately familiar. There is already a C parser written in Haskell by someone in the Haskell community, and that would probably be a good starting point.