if (bb->stmts_used < 0 || bb->stmts_size < 8
|| bb->stmts_used > bb->stmts_size)
/* this BB is so strange we can't even print it */
- vpanic("sanityCheckIRSB: stmts array limits wierd");
+ vpanic("sanityCheckIRSB: stmts array limits weird");
/* Ensure each temp has a plausible type. */
for (i = 0; i < n_temps; i++) {
Afterwards, instrumentation can be controlled in two ways: first,
interactively with: <screen>callgrind_control -i on</screen> (and
switching off again by specifying "off" instead of "on"). Second,
- instrumentation state can be programatically changed with the
+ instrumentation state can be programmatically changed with the
macros <computeroutput><xref linkend="cr.start-instr"/>;</computeroutput>
and <computeroutput><xref linkend="cr.stop-instr"/>;</computeroutput>.
</para>
<para>Similarly, the collection state at program start can be
switched off
by <option><xref linkend="opt.instr-atstart"/>=no</option>. During
- execution, it can be controlled programatically with the
+ execution, it can be controlled programmatically with the
macro <computeroutput>CALLGRIND_TOGGLE_COLLECT;</computeroutput>.
Further, you can limit event collection to a specific function by
using <option><xref linkend="opt.toggle-collect"/>=function</option>.
<para>Note that the resulting call graph will most probably not
contain <function>main</function>, but will contain all the
functions executed after instrumentation was enabled.
- Instrumentation can also programatically enabled/disabled. See the
+ Instrumentation can also be programmatically enabled/disabled. See the
Callgrind include file
<computeroutput>callgrind.h</computeroutput> for the macro
you have to use in your source code.</para> <para>For cache
if ( !sr_isError(fd) ) {
Int res = VG_(fstat)( sr_Res(fd), &stat_buf );
/* Ignore if not owned by the current user, or is not a regular file,
- or is world writeable (CVE-2008-4865). */
+ or is world writable (CVE-2008-4865). */
if (res == 0
&& stat_buf.uid == VG_(geteuid)()
&& VKI_S_ISREG(stat_buf.mode)
" Valgrind internal host status/memory\n"
" v.translate <addr> [<traceflags>] : debug translation of <addr> with <traceflags>\n"
" (default traceflags 0b00100000 : show after instrumentation)\n"
-" An additional flag 0b100000000 allows to show gdbserver instrumentation\n");
+" An additional flag 0b100000000 allows one to show gdbserver instrumentation\n");
}
break;
case 1: /* v.set */
}
VG_(message)(Vg_DebugMsg,
- "nr occurences of"
+ "nr occurrences of"
" chains of len N,"
" N-plicated keys,"
" N-plicated elts\n");
"to recompile such code, using the header files from this version of\n"
"Valgrind, and not any previous version.\n"
"\n"
- "If you see this mesage in any other circumstances, it is probably\n"
+ "If you see this message in any other circumstances, it is probably\n"
"a bug in Valgrind. In this case, please file a bug report at\n"
"\n"
" http://www.valgrind.org/support/bug_reports.html\n"
FP("n%u: %llu %s\n", n_groups, top_total, header->top_node_desc);
/* Output depth 0 groups. */
- DMSG(1, "XT_massif_print outputing %u depth 0 groups\n", n_groups);
+ DMSG(1, "XT_massif_print outputting %u depth 0 groups\n", n_groups);
for (i = 0; i < n_groups; i++)
ms_output_group(fp, 0, 0, &groups[i], sig_sz, header->sig_threshold);
Data races that occur between a statement at the end of one thread
and another thread can be missed if memory access information is
discarded immediately after a thread has been joined. This option
- allows to specify for how many joined threads memory access information
+ allows one to specify for how many joined threads memory access information
should be retained.
</para>
</listitem>
<para>
Perform segment merging only after the specified number of new
segments have been created. This is an advanced configuration option
- that allows to choose whether to minimize DRD's memory usage by
+ that allows one to choose whether to minimize DRD's memory usage by
choosing a low value or to let DRD run faster by choosing a slightly
higher value. The optimal value for this parameter depends on the
program being analyzed. The default value works well for most programs.
applications contain intentional races. There exist e.g. applications
where the same value is assigned to a shared variable from two different
threads. It may be more convenient to suppress such races than to solve
- these. This client request allows to suppress such races.
+ these. This client request allows one to suppress such races.
</para>
</listitem>
<listitem>
<listitem>
<para>
The client request <varname>VG_USERREQ__DRD_START_TRACE_ADDR</varname>,
- which allows to trace all load and store activity for the specified
+ which allows one to trace all load and store activity for the specified
address range.
</para>
</listitem>
OpenMP stands for <emphasis>Open Multi-Processing</emphasis>. The OpenMP
standard consists of a set of compiler directives for C, C++ and Fortran
programs that allows a compiler to transform a sequential program into a
-parallel program. OpenMP is well suited for HPC applications and allows to
+parallel program. OpenMP is well suited for HPC applications and allows one to
work at a higher level compared to direct use of the POSIX threads API. While
OpenMP ensures that the POSIX API is used correctly, OpenMP programs can still
contain data races. So it definitely makes sense to verify OpenMP programs
Valgrind internal host status/memory
v.translate <addr> [<traceflags>] : debug translation of <addr> with <traceflags>
(default traceflags 0b00100000 : show after instrumentation)
- An additional flag 0b100000000 allows to show gdbserver instrumentation
+ An additional flag 0b100000000 allows one to show gdbserver instrumentation
memcheck monitor commands:
xb <addr> [<len>]
prints validity bits for <len> (or 1) bytes at <addr>
projects / thirdparty / valgrind.git / commitdiff
