Started to rescind the name "skin", replacing it with "tool". Did this in all
the places that normal users will see:
- command line: --tool=foo (although --skin=foo still works)
- docs: removed all traces (included renaming coregrind_skins.html to
coregrind_tools.html)
- in the usage messages
- in error messages
Also did in in some places that I judged were unlikely to cause clashes with
existing workspaces:
- in the header comments of many files (eg. "This file is part of Memcheck, a
Valgrind tool for...")
- in the regtests script
- in the .supp files
- in AUTHORS
- in README_MISSING_SYSCALL_OR_IOCTL
Also update the AUTHORS file to mention Jeremy.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2027 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/AUTHORS b/AUTHORS
index 13a7041..4165b09 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -1,16 +1,20 @@
Julian Seward, jseward@acm.org, is the main author.
-Nicholas Nethercote, njn25@cam.ac.uk, did the core/skin
+Nicholas Nethercote, njn25@cam.ac.uk, did the core/tool
generalisation, and wrote Cachegrind and some of the other skins.
+Jeremy Fitzhardinge, jeremy@goop.org, wrote much of Helgrind, and lots
+of low-level syscall/signal stuff.
+
readelf's dwarf2 source line reader, written by Nick Clifton, was
modified to be used in Valgrind by Daniel Berlin.
Michael Matz and Simon Hausmann modified the GNU binutils
demangler(s) for use in Valgrind.
-Dirk Mueller contrib'd the malloc-free mismatch checking stuff.
+Dirk Mueller contrib'd the malloc-free mismatch checking stuff,
+and other bits and pieces.
Lots of other people sent bug reports, patches, and very
helpful feedback. I thank you all.
diff --git a/FAQ.txt b/FAQ.txt
index f97f736..93105d0 100644
--- a/FAQ.txt
+++ b/FAQ.txt
@@ -88,7 +88,7 @@
If you absolutely cannot use dynamic libraries, you can try statically
linking together all the .o files in coregrind/, all the .o files of the
- skin of your choice (eg. those in memcheck/), and the .o files of your
+ tool of your choice (eg. those in memcheck/), and the .o files of your
program. You'll end up with a statically linked binary that runs
permanently under Valgrind's control. Note that we haven't tested this
procedure thoroughly.
diff --git a/README_MISSING_SYSCALL_OR_IOCTL b/README_MISSING_SYSCALL_OR_IOCTL
index 1e049e0..761619f 100644
--- a/README_MISSING_SYSCALL_OR_IOCTL
+++ b/README_MISSING_SYSCALL_OR_IOCTL
@@ -22,17 +22,17 @@
part of a file, control passes to the Linux kernel, which fulfills the
request, and returns control to your program. The problem is that the
kernel will often change the status of some part of your program's memory
-as a result, and skins (instrumentation plug-ins) may need to know about
+as a result, and tools (instrumentation plug-ins) may need to know about
this.
Syscall and ioctl wrappers have two jobs:
-1. Tell a skin what's about to happen, before the syscall takes place. A
- skin could perform checks beforehand, eg. if memory about to be written
+1. Tell a tool what's about to happen, before the syscall takes place. A
+ tool could perform checks beforehand, eg. if memory about to be written
is actually writeable. This part is useful, but not strictly
essential.
-2. Tell a skin what just happened, after a syscall takes place. This is
+2. Tell a tool what just happened, after a syscall takes place. This is
so it can update its view of the program's state, eg. that memory has
just been written to. This step is essential.
@@ -58,7 +58,7 @@
break;
The first thing we do is, if a non-NULL buffer is passed in as the argument,
-tell the skin that the buffer is about to be written to:
+tell the tool that the buffer is about to be written to:
if (arg1 != (UInt)NULL) {
SYSCALL_TRACK( pre_mem_write, tst, "time", arg1, sizeof(time_t) );
@@ -70,7 +70,7 @@
KERNEL_DO_SYSCALL(tid, res);
Finally, the really important bit. If, and only if, the system call
-was successful, tell the skin that the memory was written:
+was successful, tell the tool that the memory was written:
if (!VG_(is_kerror)(res) && arg1 != (UInt)NULL) {
VG_TRACK( post_mem_write, arg1, sizeof(time_t) );
diff --git a/addrcheck/ac_main.c b/addrcheck/ac_main.c
index e0f2305..5407e13 100644
--- a/addrcheck/ac_main.c
+++ b/addrcheck/ac_main.c
@@ -1,12 +1,12 @@
/*--------------------------------------------------------------------*/
-/*--- The AddrCheck skin: like MemCheck, but only does address ---*/
+/*--- The AddrCheck tool: like MemCheck, but only does address ---*/
/*--- checking. No definedness checking. ---*/
/*--- ac_main.c ---*/
/*--------------------------------------------------------------------*/
/*
- This file is part of AddrCheck, a lightweight Valgrind skin for
+ This file is part of AddrCheck, a lightweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
@@ -1193,7 +1193,7 @@
VG_(message)(Vg_UserMsg, \
"Warning: Addrcheck: ignoring `%s' request.", what); \
VG_(message)(Vg_UserMsg, \
- " To honour this request, rerun with --skin=memcheck."); \
+ " To honour this request, rerun with --tool=memcheck."); \
} \
} while (0)
diff --git a/addrcheck/docs/ac_main.html b/addrcheck/docs/ac_main.html
index c998c06..b5b19c2 100644
--- a/addrcheck/docs/ac_main.html
+++ b/addrcheck/docs/ac_main.html
@@ -7,12 +7,12 @@
<a name="ac-top"></a>
<h2>5 <b>Addrcheck</b>: a lightweight memory checker</h2>
-To use this skin, you must specify <code>--skin=addrcheck</code>
+To use this tool, you must specify <code>--tool=addrcheck</code>
on the Valgrind command line.
<h3>5.1 Kinds of bugs that Addrcheck can find</h3>
-Addrcheck is a simplified version of the Memcheck skin described
+Addrcheck is a simplified version of the Memcheck tool described
in Section 3. It is identical in every way to Memcheck, except for
one important detail: it does not do the undefined-value checks that
Memcheck does. This means Addrcheck is about twice as fast as
@@ -31,7 +31,7 @@
<p>
Rather than duplicate much of the Memcheck docs here (a.k.a. since I
-am a lazy b'stard), users of the Addrcheck skin are advised to read
+am a lazy b'stard), users of Addrcheck are advised to read
the section on Memcheck. Some important points:
<ul>
<li>Addrcheck is exactly like Memcheck, except that all the
@@ -44,8 +44,8 @@
the exception of ... (to be filled in).
<p>
<li>Like Memcheck, Addrcheck will do memory leak checking (internally,
- the same code does leak checking for both skins). The only
- difference is how the two skins decide which memory locations
+ the same code does leak checking for both tools). The only
+ difference is how the two tools decide which memory locations
to consider when searching for pointers to blocks. Memcheck will
only consider 4-byte aligned locations which are validly
addressible and which hold defined values. Addrcheck does not
diff --git a/cachegrind/cg_annotate.in b/cachegrind/cg_annotate.in
index d73ee2d..9278668 100644
--- a/cachegrind/cg_annotate.in
+++ b/cachegrind/cg_annotate.in
@@ -6,7 +6,7 @@
##--- cg_annotate.in ---##
##--------------------------------------------------------------------##
-# This file is part of Cachegrind, a Valgrind skin for cache
+# This file is part of Cachegrind, a Valgrind tool for cache
# profiling programs.
#
# Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/cachegrind/cg_main.c b/cachegrind/cg_main.c
index 9307fcc..9287ae0 100644
--- a/cachegrind/cg_main.c
+++ b/cachegrind/cg_main.c
@@ -6,7 +6,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of Cachegrind, a Valgrind skin for cache
+ This file is part of Cachegrind, a Valgrind tool for cache
profiling programs.
Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/cachegrind/cg_sim_D1.c b/cachegrind/cg_sim_D1.c
index 0eaf028..a8c05de 100644
--- a/cachegrind/cg_sim_D1.c
+++ b/cachegrind/cg_sim_D1.c
@@ -5,7 +5,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of Cachegrind, a Valgrind skin for cache
+ This file is part of Cachegrind, a Valgrind tool for cache
profiling programs.
Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/cachegrind/cg_sim_I1.c b/cachegrind/cg_sim_I1.c
index db9b794..52220c2 100644
--- a/cachegrind/cg_sim_I1.c
+++ b/cachegrind/cg_sim_I1.c
@@ -5,7 +5,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of Cachegrind, a Valgrind skin for cache
+ This file is part of Cachegrind, a Valgrind tool for cache
profiling programs.
Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/cachegrind/cg_sim_L2.c b/cachegrind/cg_sim_L2.c
index ba5ece6..e38624f 100644
--- a/cachegrind/cg_sim_L2.c
+++ b/cachegrind/cg_sim_L2.c
@@ -5,7 +5,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of Cachegrind, a Valgrind skin for cache
+ This file is part of Cachegrind, a Valgrind tool for cache
profiling programs.
Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/cachegrind/cg_sim_gen.c b/cachegrind/cg_sim_gen.c
index a5c1df0..57cb932 100644
--- a/cachegrind/cg_sim_gen.c
+++ b/cachegrind/cg_sim_gen.c
@@ -5,7 +5,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of Cachegrind, a Valgrind skin for cache
+ This file is part of Cachegrind, a Valgrind tool for cache
profiling programs.
Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/cachegrind/docs/cg_main.html b/cachegrind/docs/cg_main.html
index 6449e81..545748a 100644
--- a/cachegrind/docs/cg_main.html
+++ b/cachegrind/docs/cg_main.html
@@ -7,7 +7,7 @@
<a name="cg-top"></a>
<h2>4 <b>Cachegrind</b>: a cache-miss profiler</h2>
-To use this skin, you must specify <code>--skin=cachegrind</code>
+To use this tool, you must specify <code>--tool=cachegrind</code>
on the Valgrind command line.
<p>
@@ -44,7 +44,7 @@
The two steps are:
<ol>
- <li>Run your program with <code>valgrind --skin=cachegrind</code> in front of
+ <li>Run your program with <code>valgrind --tool=cachegrind</code> in front of
the normal command line invocation. When the program finishes,
Cachegrind will print summary cache statistics. It also collects
line-by-line information in a file
@@ -144,11 +144,10 @@
<a name="profile"></a>
<h3>4.4 Profiling programs</h3>
-Cache profiling is enabled by using the <code>--skin=cachegrind</code>
-option to the <code>valgrind</code> shell script. To gather cache profiling
-information about the program <code>ls -l</code>, type:
+To gather cache profiling information about the program <code>ls -l</code>,
+invoke Cachegrind like this:
-<blockquote><code>valgrind --skin=cachegrind ls -l</code></blockquote>
+<blockquote><code>valgrind --tool=cachegrind ls -l</code></blockquote>
The program will execute (slowly). Upon completion, summary statistics
that look like this will be printed:
@@ -193,7 +192,7 @@
<p>
Things to note about the <code>cachegrind.out.<i>pid</i></code> file:
<ul>
- <li>It is written every time <code>valgrind --skin=cachegrind</code>
+ <li>It is written every time Cachegrind
is run, and will overwrite any existing
<code>cachegrind.out.<i>pid</i></code> in the current directory (but
that won't happen very often because it takes some time for process ids
@@ -229,7 +228,7 @@
three items must be comma-separated, but with no spaces, eg:
<blockquote>
- <code>valgrind --skin=cachegrind --I1=65535,2,64</code>
+ <code>valgrind --tool=cachegrind --I1=65535,2,64</code>
</blockquote>
You can specify one, two or three of the I1/D1/L2 caches. Any level not
@@ -350,7 +349,7 @@
</ul>
Then follows summary statistics for the whole program. These are similar
-to the summary provided when running <code>valgrind --skin=cachegrind</code>.<p>
+to the summary provided when running <code>valgrind --tool=cachegrind</code>.<p>
Then follows function-by-function statistics. Each function is
identified by a <code>file_name:function_name</code> pair. If a column
diff --git a/corecheck/cc_main.c b/corecheck/cc_main.c
index b30d94c..86a150d 100644
--- a/corecheck/cc_main.c
+++ b/corecheck/cc_main.c
@@ -1,11 +1,11 @@
/*--------------------------------------------------------------------*/
-/*--- CoreCheck: a skin reporting errors detected in core. ---*/
+/*--- CoreCheck: a tool reporting errors detected in core. ---*/
/*--- cc_main.c ---*/
/*--------------------------------------------------------------------*/
/*
- This file is part of CoreCheck, a rudimentary Valgrind skin for
+ This file is part of CoreCheck, a rudimentary Valgrind tool for
detecting certain basic program errors.
Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/corecheck/docs/cc_main.html b/corecheck/docs/cc_main.html
index a41e69a..2d63877 100644
--- a/corecheck/docs/cc_main.html
+++ b/corecheck/docs/cc_main.html
@@ -35,14 +35,14 @@
<p>
CoreCheck is licensed under the GNU General Public License,
version 2<br>
-CoreCheck is a Valgrind skin that does very basic error checking.
+CoreCheck is a Valgrind tool that does very basic error checking.
</center>
<p>
<h2>1 CoreCheck</h2>
-CoreCheck is a very simple skin for Valgrind. It adds no instrumentation to
+CoreCheck is a very simple tool for Valgrind. It adds no instrumentation to
the program's code, and only reports the few kinds of errors detected by
Valgrind's core. It is mainly of use for Valgrind's developers for debugging
and regression testing.
diff --git a/coregrind/docs/Makefile.am b/coregrind/docs/Makefile.am
index 1adb3de..9bdfcc0 100644
--- a/coregrind/docs/Makefile.am
+++ b/coregrind/docs/Makefile.am
@@ -1,5 +1,5 @@
docdir = $(datadir)/doc/valgrind
-doc_DATA = coregrind_core.html coregrind_intro.html coregrind_skins.html
+doc_DATA = coregrind_core.html coregrind_intro.html coregrind_tools.html
EXTRA_DIST = $(doc_DATA)
diff --git a/coregrind/docs/coregrind_core.html b/coregrind/docs/coregrind_core.html
index cbf6245..6ae2802 100644
--- a/coregrind/docs/coregrind_core.html
+++ b/coregrind/docs/coregrind_core.html
@@ -4,7 +4,7 @@
<h2>2 Using and understanding the Valgrind core services</h2>
This section describes the core services, flags and behaviours. That
-means it is relevant regardless of what particular skin you are using.
+means it is relevant regardless of what particular tool you are using.
A point of terminology: most references to "valgrind" in the rest of
this section (Section 2) refer to the valgrind core services.
@@ -16,21 +16,21 @@
directly with existing executables. You don't need to recompile,
relink, or otherwise modify, the program to be checked. Simply place
the word <code>valgrind</code> at the start of the command line
-normally used to run the program, and tell it what skin you want to
+normally used to run the program, and tell it what tool you want to
use.
<p>
So, for example, if you want to run the command <code>ls -l</code>
using the heavyweight memory-checking tool, issue the command:
-<code>valgrind --skin=memcheck ls -l</code>. The <code>--skin=</code>
-parameter tells the core which skin is to be used.
+<code>valgrind --tool=memcheck ls -l</code>. The <code>--tool=</code>
+parameter tells the core which tool is to be used.
<p>
To preserve compatibility with the 1.0.X series, if you do not specify
-a skin, the default is to use the memcheck skin. That means the above
+a tool, the default is to use Memcheck. That means the above
example simplifies to: <code>valgrind ls -l</code>.
-<p>Regardless of which skin is in use, Valgrind takes control of your
+<p>Regardless of which tool is in use, Valgrind takes control of your
program before it starts. Debugging information is read from the
executable and associated libraries, so that error messages can be
phrased in terms of source code locations (if that is appropriate).
@@ -38,29 +38,29 @@
<p>
Your program is then run on a synthetic x86 CPU provided by the
valgrind core. As new code is executed for the first time, the core
-hands the code to the selected skin. The skin adds its own
+hands the code to the selected tool. The tool adds its own
instrumentation code to this and hands the result back to the core,
which coordinates the continued execution of this instrumented code.
<p>
-The amount of instrumentation code added varies widely between skins.
-At one end of the scale, the memcheck skin adds code to check every
+The amount of instrumentation code added varies widely between tools.
+At one end of the scale, Memcheck adds code to check every
memory access and every value computed, increasing the size of the
code at least 12 times, and making it run 25-50 times slower than
natively. At the other end of the spectrum, the ultra-trivial "none"
-skin adds no instrumentation at all and causes in total "only" about a
+tool adds no instrumentation at all and causes in total "only" about a
4 times slowdown.
<p>
Valgrind simulates every single instruction your program executes.
-Because of this, the active skin checks, or profiles, not only the
+Because of this, the active tool checks, or profiles, not only the
code in your application but also in all supporting dynamically-linked
(<code>.so</code>-format) libraries, including the GNU C library, the
X client libraries, Qt, if you work with KDE, and so on.
<p>
If -- as is usually the case -- you're using one of the
-error-detection skins, valgrind will often detect errors in
+error-detection tools, valgrind will often detect errors in
libraries, for example the GNU C or X11 libraries, which you have to
use. Since you're probably using valgrind to debug your own
application, and not those libraries, you don't want to see those
@@ -78,8 +78,8 @@
then copy into a suppressions file.
<p>
-Different skins report different kinds of errors. The suppression
-mechanism therefore allows you to say which skin or skin(s) each
+Different tools report different kinds of errors. The suppression
+mechanism therefore allows you to say which tool or tool(s) each
suppression applies to.
@@ -109,18 +109,18 @@
or some other debugger.
<p>
-This paragraph applies only if you plan to use the memcheck
-skin (which is the default): On rare occasions, optimisation levels
+This paragraph applies only if you plan to use Memcheck
+(which is the default): On rare occasions, optimisation levels
at <code>-O2</code> and above have been observed to generate code which
-fools memcheck into wrongly reporting uninitialised value
+fools Memcheck into wrongly reporting 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 skin. So the best solution is to turn off
+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 plausible compromise is to use <code>-O</code>. This gets
you the majority of the benefits of higher optimisation levels whilst
-keeping relatively small the chances of false complaints from memcheck.
-All other skins (as far as we know) are unaffected by optimisation
+keeping relatively small the chances of false complaints from Memcheck.
+All other tools (as far as we know) are unaffected by optimisation
level.
<p>
@@ -132,7 +132,7 @@
<p>
When you're ready to roll, just run your application as you would
-normally, but place <code>valgrind --skin=the-selected-skin</code> in
+normally, but place <code>valgrind --tool=the-selected-tool</code> in
front of your usual command-line invocation. Note that you should run
the real (machine-code) executable here. If your application is
started by, for example, a shell or perl script, you'll need to modify
@@ -234,11 +234,11 @@
</ul>
<p>
Here is an important point about the relationship between the
-commentary and profiling output from skins. The commentary contains a
-mix of messages from the valgrind core and the selected skin. If the
-skin reports errors, it will report them to the commentary. However,
-if the skin does profiling, the profile data will be written to a file
-of some kind, depending on the skin, and independent of what
+commentary and profiling output from tools. The commentary contains a
+mix of messages from the valgrind core and the selected tool. If the
+tool reports errors, it will report them to the commentary. However,
+if the tool does profiling, the profile data will be written to a file
+of some kind, depending on the tool, and independent of what
<code>--log*</code> options are in force. The commentary is intended
to be a low-bandwidth, human-readable channel. Profiling data, on the
other hand, is usually voluminous and not meaningful without further
@@ -248,7 +248,7 @@
<a name="report"></a>
<h3>2.4 Reporting of errors</h3>
-When one of the error-checking skins (memcheck, addrcheck, helgrind)
+When one of the error-checking tools (Memcheck, Addrcheck, Helgrind)
detects something bad happening in the program, an error message is
written to the commentary. For example:<br>
<pre>
@@ -262,7 +262,7 @@
<p>
This message says that the program did an illegal 4-byte read of
-address 0xBFFFF74C, which, as far as memcheck can tell, is not a valid
+address 0xBFFFF74C, which, as far as Memcheck can tell, is not a valid
stack address, nor corresponds to any currently malloc'd or free'd
blocks. The read is happening at line 45 of <code>bogon.cpp</code>,
called from line 66 of the same file, etc. For errors associated with
@@ -284,9 +284,9 @@
<p>
Errors are reported before the associated operation actually happens.
-If you're using a skin (memcheck, addrcheck) which does address
+If you're using a tool (Memcheck, Addrcheck) which does address
checking, and your program attempts to read from address zero, the
-skin will emit a message to this effect, and the program will then
+tool will emit a message to this effect, and the program will then
duly die with a segmentation fault.
<p>
@@ -294,7 +294,7 @@
reported. Not doing so can be confusing. For example, a program
which copies uninitialised values to several memory locations, and
later uses them, will generate several error messages, when run on
-memcheck. The first such error message may well give the most direct
+Memcheck. The first such error message may well give the most direct
clue to the root cause of the problem.
<p>
@@ -319,7 +319,7 @@
<a name="suppress"></a>
<h3>2.5 Suppressing errors</h3>
-The error-checking skins detect numerous problems in the base
+The error-checking tools detect numerous problems in the base
libraries, such as the GNU C library, and the XFree86 client
libraries, which come pre-installed on your GNU/Linux system. You
can't easily fix these, but you don't want to see these errors (and
@@ -350,7 +350,7 @@
If you use the <code>-v</code> flag, at the end of execution, Valgrind
prints out one line for each used suppression, giving its name and the
number of times it got used. Here's the suppressions used by a run of
-<code>valgrind --skin=memcheck ls -l</code>:
+<code>valgrind --tool=memcheck ls -l</code>:
<pre>
--27579-- supp: 1 socketcall.connect(serv_addr)/__libc_connect/__nscd_getgrgid_r
--27579-- supp: 1 socketcall.connect(serv_addr)/__libc_connect/__nscd_getpwuid_r
@@ -378,24 +378,24 @@
</li>
<p>
- <li>Second line: name of the skin(s) that the suppression is for (if more
+ <li>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, eg:
<pre>
- skin_name1,skin_name2:suppression_name
+ tool_name1,tool_name2:suppression_name
</pre>
(Nb: no spaces are allowed).
<p>
Recall that valgrind-2.0.X is a modular system, in which
different instrumentation tools can observe your program whilst
it is running. Since different tools detect different kinds of
- errors, it is necessary to say which skin(s) the suppression is
+ errors, it is necessary to say which tool(s) the suppression is
meaningful to.
<p>
- Skins will complain, at startup, if a skin does not understand
- any suppression directed to it. Skins ignore suppressions which
+ Tools will complain, at startup, if a tool does not understand
+ any suppression directed to it. Tools ignore suppressions which
are not directed to them. As a result, it is quite practical to
- put suppressions for all skins into the same suppression file.
+ put suppressions for all tools into the same suppression file.
<p>
Valgrind's core can detect certain PThreads API errors, for which this
line reads:
@@ -439,7 +439,7 @@
}
</pre>
-<p>What is means is: in the Memcheck skin only, suppress a
+<p>What is means is: for Memcheck only, suppress a
use-of-uninitialised-value error, when the data size is 4, when it
occurs in the function <code>__gconv_transform_ascii_internal</code>,
when that is called from any function of name matching
@@ -451,7 +451,7 @@
(See <a href="mc_main.html#suppfiles">this section</a> for more details on
the specifics of Memcheck's suppression kinds.)
-<p>Another example, again for the Memcheck skin:
+<p>Another example, again for the Memcheck tool:
<pre>
{
libX11.so.6.2/libX11.so.6.2/libXaw.so.7.0
@@ -479,8 +479,8 @@
As mentioned above, valgrind's core accepts a common set of flags.
-The skins also accept skin-specific flags, which are documented
-seperately for each skin.
+The tools also accept tool-specific flags, which are documented
+seperately for each tool.
You invoke Valgrind like this:
<pre>
@@ -490,34 +490,34 @@
<p>Note that Valgrind also reads options from the environment variable
<code>$VALGRIND_OPTS</code>, and processes them before the command-line
options. Options for the valgrind core may be freely mixed with those
-for the selected skin.
+for the selected tool.
<p>Valgrind's default settings succeed in giving reasonable behaviour
in most cases. We group the available options by rough categories.
-<h4>Skin-selection option</h4>
+<h4>Tool-selection option</h4>
The single most important option.
<ul>
- <li><code>--skin=<i>name</i></code><br>
+ <li><code>--tool=<i>name</i></code><br>
<p>Run the Valgrind tool called <i>name</i>, e.g. Memcheck, Addrcheck,
Cachegrind, etc.
</li><br><p>
</ul>
<h4>Basic Options</h4>
-These options work with all skins.
+These options work with all tools.
<ul>
<li><code>--help</code><br>
<p>Show help for all options, both for the core and for the
- selected skin. </li><br><p>
+ selected tool. </li><br><p>
<li><code>--version</code><br> <p>Show the version number of the
- valgrind core. Skins can have their own version numbers. There
- is a scheme in place to ensure that skins only execute when the
+ valgrind core. Tools can have their own version numbers. There
+ is a scheme in place to ensure that tools only execute when the
core version is one they are known to work with. This was done
to minimise the chances of strange problems arising from
- skin-vs-core version incompatibilities. </li><br><p>
+ tool-vs-core version incompatibilities. </li><br><p>
<li><code>-v --verbose</code><br> <p>Be more verbose. Gives extra
information on various aspects of your program, such as: the
@@ -567,7 +567,7 @@
</ul>
<h4>Error-related options</h4>
-These options are used by all skins that can report errors, e.g. Memcheck, but
+These options are used by all tools that can report errors, e.g. Memcheck, but
not Cachegrind.
<ul>
<li><code>--demangle=no</code><br>
@@ -706,7 +706,7 @@
</ul>
<h4><code>malloc()</code>-related options</h4>
-For skins that use their own version of <code>malloc()</code> (e.g. Memcheck
+For tools that use their own version of <code>malloc()</code> (e.g. Memcheck
and Addrcheck), the following options apply.
<ul>
<li><code>--alignment=<number></code> [default: 4]<br> <p>By
@@ -743,7 +743,7 @@
</ul>
<h4>Rare options</h4>
-These options apply to all skins, as they affect certain obscure workings of
+These options apply to all tools, as they affect certain obscure workings of
the Valgrind core. Most people won't need to use these.
<ul>
<li><code>--run-libc-freeres=yes</code> [default]<br>
@@ -760,7 +760,7 @@
when a leak check is done at exit. In order to avoid this, they
provided a routine called <code>__libc_freeres</code>
specifically to make glibc release all memory it has allocated.
- The MemCheck and AddrCheck skins therefore try and run
+ Memcheck and Addrcheck therefore try and run
<code>__libc_freeres</code> at exit.
<p>
Unfortunately, in some versions of glibc,
@@ -888,7 +888,7 @@
<p>When enabled, does crude internal profiling of valgrind
itself. This is not for profiling your programs. Rather it is
to allow the developers to assess where valgrind is spending
- its time. The skins must be built for profiling for this to
+ its time. The tools must be built for profiling for this to
work.
</li><br><p>
@@ -953,7 +953,7 @@
<h3>2.7 The Client Request mechanism</h3>
Valgrind has a trapdoor mechanism via which the client program can
-pass all manner of requests and queries to Valgrind and the current skin.
+pass all manner of requests and queries to Valgrind and the current tool.
Internally, this is used extensively to make malloc, free, signals, threads,
etc, work, although you don't see that.
<p>
@@ -967,7 +967,7 @@
Clients need to include a header file to make this work. Which header file
depends on which client requests you use. Some client requests are handled by
the core, and are defined in the header file <code>valgrind.h</code>.
-Skin-specific header files are named after the skin, e.g.
+Tool-specific header files are named after the tool, e.g.
<code>memcheck.h</code>. All header files can be found in the
<code>include</code> directory of wherever Valgrind was installed.
<p>
@@ -979,8 +979,8 @@
supporting libraries.
<p>
Here is a brief description of the macros available in
-<code>valgrind.h</code>, which work with more than one skin (see the
-skin-specific documentation for explanations of the skin-specific macros).
+<code>valgrind.h</code>, which work with more than one tool (see the
+tool-specific documentation for explanations of the tool-specific macros).
<ul>
<li><code>RUNNING_ON_VALGRIND</code>: returns 1 if running on
Valgrind, 0 if running on the real CPU.
@@ -1000,19 +1000,19 @@
fresh memory, and just call this occasionally to discard large
chunks of old code all at once.
<p>
- Warning: minimally tested, especially for skins other than Memcheck.
+ Warning: minimally tested, especially for tools other than Memcheck.
<p>
<li><code>VALGRIND_COUNT_ERRORS</code>: returns the number of errors
found so far by Valgrind. Can be useful in test harness code when
combined with the <code>--logfile-fd=-1</code> option; this runs
Valgrind silently, but the client program can detect when errors
- occur. Only useful for skins that report errors, e.g. it's useful for
+ occur. Only useful for tools that report errors, e.g. it's useful for
Memcheck, but for Cachegrind it will always return zero because
Cachegrind doesn't report errors.
<p>
<li><code>VALGRIND_MALLOCLIKE_BLOCK</code>: If your program manages its own
memory instead of using the standard
- <code>malloc()</code>/<code>new</code>/<code>new[]</code>, skins that track
+ <code>malloc()</code>/<code>new</code>/<code>new[]</code>, tools that track
information about heap blocks will not do nearly as good a
job. For example, Memcheck won't detect nearly as many errors, and the
error messages won't be as informative. To improve this situation, use
@@ -1040,9 +1040,9 @@
Returns the number of characters output.
<p>
</ul>
-Note that <code>valgrind.h</code> is included by all the skin-specific header
+Note that <code>valgrind.h</code> is included by all the tool-specific header
files (such as <code>memcheck.h</code>), so you don't need to include it in
-your client if you include a skin-specific header.
+your client if you include a tool-specific header.
<p>
@@ -1200,7 +1200,7 @@
badly.</li>
<p>
- <li>The memcheck skin assumes that the floating point registers are
+ <li>Memcheck assumes that the floating point registers are
not used as intermediaries in memory-to-memory copies, so it
immediately checks definedness of values loaded from memory by
floating-point loads. If you want to write code which copies
@@ -1443,8 +1443,8 @@
<a name="example"></a>
<h3>2.14 An example run</h3>
-This is the log for a run of a small program using the memcheck
-skin. The program is in fact correct, and the reported error is as the
+This is the log for a run of a small program using Memcheck
+The program is in fact correct, and the reported error is as the
result of a potentially serious code generation bug in GNU g++
(snapshot 20010527).
<pre>
diff --git a/coregrind/docs/coregrind_intro.html b/coregrind/docs/coregrind_intro.html
index f115e99..fdc5ee8 100644
--- a/coregrind/docs/coregrind_intro.html
+++ b/coregrind/docs/coregrind_intro.html
@@ -6,25 +6,21 @@
<a name="intro-overview"></a>
<h3>1.1 An overview of Valgrind</h3>
-Valgrind is a flexible tool for debugging and profiling Linux-x86
-executables. The tool consists of a core, which provides a synthetic
-x86 CPU in software, and a series of "skins", each of which is a
-debugging or profiling tool. The architecture is modular, so that new
-skins can be created easily and without disturbing the existing
-structure.
+Valgrind is a flexible system for debugging and profiling Linux-x86
+executables. The system consists of a core, which provides a synthetic
+x86 CPU in software, and a series of tools, each of which performs some
+kind of debugging, profiling, or similar task. The architecture is
+modular, so that new tools can be created easily and without disturbing
+the existing structure.
<p>
-A number of useful skins are supplied as standard. In summary, these
+A number of useful tools are supplied as standard. In summary, these
are:
<ul>
-<li>The <b>memcheck</b> skin detects memory-management problems in
- your programs. It provides services identical to those supplied
- by the valgrind-1.0.X series. Memcheck is essentially
- valgrind-1.0.X packaged up into a skin.
- <p>
+<li><b>Memcheck</b> detects memory-management problems in your programs.
All reads and writes of memory are checked, and calls to
- malloc/new/free/delete are intercepted. As a result, memcheck can
+ malloc/new/free/delete are intercepted. As a result, Memcheck can
detect the following problems:
<ul>
<li>Use of uninitialised memory</li>
@@ -43,8 +39,7 @@
lying undetected for long periods, then causing occasional,
difficult-to-diagnose crashes.
<p>
-<li><b>cachegrind</b> is a packaging of Nick Nethercote's cache
- profiler from valgrind-1.0.X. It performs detailed simulation of
+<li><b>Cachegrind</b> is a cache profiler. It performs detailed simulation of
the I1, D1 and L2 caches in your CPU and so can accurately
pinpoint the sources of cache misses in your code. If you desire,
it will show the number of cache misses, memory references and
@@ -64,34 +59,34 @@
presents these profiling results in a graphical and
easier-to-understand form.
<p>
-<li>The new <b>addrcheck</b> skin is a lightweight version of
- memcheck. It is identical to memcheck except
+<li><b>Addrcheck</b> is a lightweight version of
+ Memcheck. It is identical to Memcheck except
for the single detail that it does not do any uninitialised-value
checks. All of the other checks -- primarily the fine-grained
address checking -- are still done. The downside of this is that
you don't catch the uninitialised-value errors that
- memcheck can find.
+ Memcheck can find.
<p>
But the upside is significant: programs run about twice as fast as
- they do on memcheck, and a lot less memory is used. It
+ they do on Memcheck, and a lot less memory is used. It
still finds reads/writes of freed memory, memory off the end of
blocks and in other invalid places, bugs which you really want to
find before release!
<p>
- Because addrcheck is lighter and faster than
- memcheck, you can run more programs for longer, and so you
+ Because Addrcheck is lighter and faster than
+ Memcheck, you can run more programs for longer, and so you
may be able to cover more test scenarios. Addrcheck was
created because one of us (Julian) wanted to be able to
run a complete KDE desktop session with checking. As of early
November 2002, we have been able to run KDE-3.0.3 on a 1.7 GHz P4
- with 512 MB of memory, using addrcheck. Although the
+ with 512 MB of memory, using Addrcheck. Although the
result is not stellar, it's quite usable, and it seems plausible
to run KDE for long periods at a time like this, collecting up
all the addressing errors that appear.
<p>
-<li><b>helgrind</b> is a new debugging skin, designed to find data
- races in multithreaded programs. What helgrind looks for
- is memory locations which are accessed by more than one (POSIX
+<li><b>Helgrind</b> finds data races in multithreaded programs.
+ Helgrind looks for
+ memory locations which are accessed by more than one (POSIX
p-)thread, but for which no consistently used (pthread_mutex_)lock
can be found. Such locations are indicative of missing
synchronisation between threads, and could cause hard-to-find
@@ -101,16 +96,16 @@
so-called "Eraser" data-race-detection algorithm, along with
various refinements (thread-segment lifetimes) which reduce the
number of false errors it reports. It is as yet somewhat of an
- experimental skin, so your feedback is especially welcomed here.
+ experimental tool, so your feedback is especially welcomed here.
<p>
Helgrind has been hacked on extensively by Jeremy
Fitzhardinge, and we have him to thank for getting it to a
releasable state.
</ul>
-A number of minor skins (<b>corecheck</b>, <b>lackey</b> and
+A number of minor tools (<b>corecheck</b>, <b>lackey</b> and
<b>none</b>) are also supplied. These aren't particularly useful --
-they exist to illustrate how to create simple skins and to help the
+they exist to illustrate how to create simple tools and to help the
valgrind developers in various ways.
@@ -143,36 +138,36 @@
<h3>1.2 How to navigate this manual</h3>
Valgrind is structured as a set of core services supporting a number
-of profiling and debugging tools ("skins"). This manual is structured
+of profiling and debugging tools. This manual is structured
similarly. Below, we continue with a description of the valgrind
core, how to use it, and the flags it supports.
<p>
-The skins each have their own chapters in this manual. You only need
-to read the documentation for the core services and for the skin(s)
+The tools each have their own chapters in this manual. You only need
+to read the documentation for the core services 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 skins do. If you want to write a new
-skin, read <A HREF="coregrind_skins.html">this</A>.
+little bit familar with what all tools do. If you want to write a new
+tool, read <A HREF="coregrind_tools.html">this</A>.
<p>
If you're new to all this, you're most likely to be using the Memcheck
-skin, since that's the one selected by default. So, read the rest of
+tool, since that's the one selected by default. So, read the rest of
this page, and the section Memcheck.
<p>
Be aware that the core understands some command line flags, and the
-skins have their own flags which they know about. This means
+tools have their own flags which they know about. This means
there is no central place describing all the flags that are accepted
-- you have to read the flags documentation both for
<A HREF="coregrind_core.html#core">valgrind's core</A>
-and for the skin you want to use.
+and for the tool you want to use.
<p>
<a name="intro-migrating"></a>
<h4>1.2.1 For users migrating from valgrind-1.0.X</h4>
<p>
Valgrind-2.0.X is a major redesign of the 1.0.X series. You should at
-least be familiar with the concept of the new core/skin division,
+least be familiar with the concept of the core/tool division,
as explained above in the Introduction. Having said that, we've tried
to make the command line handling and behaviour as
backwards-compatible as we can. In particular, just running
diff --git a/coregrind/docs/coregrind_skins.html b/coregrind/docs/coregrind_tools.html
similarity index 81%
rename from coregrind/docs/coregrind_skins.html
rename to coregrind/docs/coregrind_tools.html
index 8878dfe..17927bd 100644
--- a/coregrind/docs/coregrind_skins.html
+++ b/coregrind/docs/coregrind_tools.html
@@ -25,9 +25,9 @@
<body bgcolor="#ffffff">
<a name="title"> </a>
-<h1 align=center>Valgrind Skins</h1>
+<h1 align=center>Valgrind Tools</h1>
<center>
- A guide to writing new skins for Valgrind<br>
+ A guide to writing new tools for Valgrind<br>
This guide was last updated on 20030520
</center>
<p>
@@ -49,13 +49,13 @@
<h4>1 <a href="#intro">Introduction</a></h4>
1.1 <a href="#supexec">Supervised Execution</a><br>
- 1.2 <a href="#skins">Skins</a><br>
+ 1.2 <a href="#tools">Tools</a><br>
1.3 <a href="#execspaces">Execution Spaces</a><br>
-<h4>2 <a href="#writingaskin">Writing a Skin</a></h4>
- 2.1 <a href="#whywriteaskin">Why write a skin?</a><br>
- 2.2 <a href="#suggestedskins">Suggested skins</a><br>
- 2.3 <a href="#howskinswork">How skins work</a><br>
+<h4>2 <a href="#writingatool">Writing a Tool</a></h4>
+ 2.1 <a href="#whywriteatool">Why write a tool?</a><br>
+ 2.2 <a href="#suggestedtools">Suggested tools</a><br>
+ 2.3 <a href="#howtoolswork">How tools work</a><br>
2.4 <a href="#gettingcode">Getting the code</a><br>
2.5 <a href="#gettingstarted">Getting started</a><br>
2.6 <a href="#writingcode">Writing the code</a><br>
@@ -71,7 +71,7 @@
3.3 <a href="#regressiontests">Regression tests</a><br>
3.4 <a href="#profiling">Profiling</a><br>
3.5 <a href="#othermakefilehackery">Other makefile hackery</a><br>
- 3.6 <a href="#interfaceversions">Core/skin interface versions</a><br>
+ 3.6 <a href="#interfaceversions">Core/tool interface versions</a><br>
<h4>4 <a href="#finalwords">Final Words</a></h4>
@@ -88,38 +88,35 @@
precise ways, making it relatively easy to support activities such as dynamic
error detection and profiling.<p>
-Although writing a skin is not easy, and requires learning quite a few things
+Although writing a tool is not easy, and requires learning quite a few things
about Valgrind, it is much easier than instrumenting a program from scratch
yourself.
-<a name="skins"></a>
-<h3>1.2 Skins</h3>
+<a name="tools"></a>
+<h3>1.2 Tools</h3>
The key idea behind Valgrind's architecture is the division between its
-``core'' and ``skins''.
+``core'' and ``tools''.
<p>
The core provides the common low-level infrastructure to support program
instrumentation, including the x86-to-x86 JIT compiler, low-level memory
manager, signal handling and a scheduler (for pthreads). It also provides
-certain services that are useful to some but not all skins, such as support
+certain services that are useful to some but not all tools, such as support
for error recording and suppression.
<p>
-But the core leaves certain operations undefined, which must be filled by skins.
-Most notably, skins define how program code should be instrumented. They can
+But the core leaves certain operations undefined, which must be filled by tools.
+Most notably, tools define how program code should be instrumented. They can
also define certain variables to indicate to the core that they would like to
use certain services, or be notified when certain interesting events occur.
-<p>
-Each skin that is written defines a new program supervision tool. Writing a
-new tool just requires writing a new skin. The core takes care of all the hard
-work.
+But the core takes care of all the hard work.
<p>
<a name="execspaces"></a>
<h3>1.3 Execution Spaces</h3>
-An important concept to understand before writing a skin is that there are
+An important concept to understand before writing a tool is that there are
three spaces in which program code executes:
<ol>
- <li>User space: this covers most of the program's execution. The skin is
+ <li>User space: this covers most of the program's execution. The tool is
given the code and can instrument it any way it likes, providing (more or
less) total control over the code.<p>
@@ -139,24 +136,24 @@
<li>Signal handling</li>
</ul><p>
- A skin has no control over these operations; it never ``sees'' the code
+ A tool has no control over these operations; it never ``sees'' the code
doing this work and thus cannot instrument it. However, the core
- provides hooks so a skin can be notified when certain interesting events
+ provides hooks so a tool can be notified when certain interesting events
happen, for example when when dynamic memory is allocated or freed, the
stack pointer is changed, or a pthread mutex is locked, etc.<p>
- Note that these hooks only notify skins of events relevant to user
+ Note that these hooks only notify tools of events relevant to user
space. For example, when the core allocates some memory for its own use,
- the skin is not notified of this, because it's not directly part of the
+ the tool is not notified of this, because it's not directly part of the
supervised program's execution.
</li><p>
<li>Kernel space: execution in the kernel. Two kinds:<p>
<ol>
- <li>System calls: can't be directly observed by either the skin or the
+ <li>System calls: can't be directly observed by either the tool or the
core. But the core does have some idea of what happens to the
- arguments, and it provides hooks for a skin to wrap system calls.
+ arguments, and it provides hooks for a tool to wrap system calls.
</li><p>
<li>Other: all other kernel activity (e.g. process scheduling) is
@@ -165,22 +162,22 @@
</ol>
</li><p>
- It should be noted that a skin only has direct control over code executed in
+ It should be noted that a tool only has direct control over code executed in
user space. This is the vast majority of code executed, but it is not
- absolutely all of it, so any profiling information recorded by a skin won't
+ absolutely all of it, so any profiling information recorded by a tool won't
be totally accurate.
</ol>
-<a name="writingaskin"></a>
-<h2>2 Writing a Skin</h2>
+<a name="writingatool"></a>
+<h2>2 Writing a Tool</h2>
-<a name="whywriteaskin"></a>
-<h3>2.1 Why write a skin?</h3>
+<a name="whywriteatool"></a>
+<h3>2.1 Why write a tool?</h3>
-Before you write a skin, you should have some idea of what it should do. What
+Before you write a tool, you should have some idea of what it should do. What
is it you want to know about your programs of interest? Consider some existing
-skins:
+tools:
<ul>
<li>memcheck: among other things, performs fine-grained validity and
@@ -209,10 +206,10 @@
memcheck's memory checking).
-<a name="suggestedskins"></a>
-<h3>2.2 Suggested skins</h3>
+<a name="suggestedtools"></a>
+<h3>2.2 Suggested tools</h3>
-Here is a list of ideas we have had for skins that should not be too hard to
+Here is a list of ideas we have had for tools that should not be too hard to
implement.
<ul>
@@ -242,7 +239,7 @@
In addition to the standard coverage information, such a tool could
record extra information that would help a user generate test cases to
exercise unexercised paths. For example, for each conditional branch,
- the skin could record all inputs to the conditional test, and print these
+ the tool could record all inputs to the conditional test, and print these
out when annotating.<p>
<li>run-time type checking: A nice example of a dynamic checker is given
@@ -266,7 +263,7 @@
</blockquote>
These approach can find quite a range of bugs, particularly in C and C++
- programs, and could be implemented quite nicely as a Valgrind skin.<p>
+ programs, and could be implemented quite nicely as a Valgrind tool.<p>
Ways to speed up this run-time type checking are described in this paper:
@@ -277,39 +274,39 @@
July 2002.
</blockquote>
- Valgrind's client requests could be used to pass information to a skin
+ Valgrind's client requests could be used to pass information to a tool
about which elements need instrumentation and which don't.
</li><p>
</ul>
-We would love to hear from anyone who implements these or other skins.
+We would love to hear from anyone who implements these or other tools.
-<a name="howskinswork"></a>
-<h3>2.3 How skins work</h3>
+<a name="howtoolswork"></a>
+<h3>2.3 How tools work</h3>
-Skins must define various functions for instrumenting programs that are called
+Tools must define various functions for instrumenting programs that are called
by Valgrind's core, yet they must be implemented in such a way that they can be
written and compiled without touching Valgrind's core. This is important,
because one of our aims is to allow people to write and distribute their own
-skins that can be plugged into Valgrind's core easily.<p>
+tools that can be plugged into Valgrind's core easily.<p>
-This is achieved by packaging each skin into a separate shared object which is
+This is achieved by packaging each tool into a separate shared object which is
then loaded ahead of the core shared object <code>valgrind.so</code>, using the
dynamic linker's <code>LD_PRELOAD</code> variable. Any functions defined in
-the skin that share the name with a function defined in core (such as
+the tool that share the name with a function defined in core (such as
the instrumentation function <code>SK_(instrument)()</code>) override the
-core's definition. Thus the core can call the necessary skin functions.<p>
+core's definition. Thus the core can call the necessary tool functions.<p>
This magic is all done for you; the shared object used is chosen with the
-<code>--skin</code> option to the <code>valgrind</code> startup script. The
-default skin used is <code>memcheck</code>, Valgrind's original memory checker.
+<code>--tool</code> option to the <code>valgrind</code> startup script. The
+default tool used is <code>memcheck</code>, Valgrind's original memory checker.
<a name="gettingcode"></a>
<h3>2.4 Getting the code</h3>
-To write your own skin, you'll need to check out a copy of Valgrind from the
+To write your own tool, you'll need to check out a copy of Valgrind from the
CVS repository, rather than using a packaged distribution. This is because it
-contains several extra files needed for writing skins.<p>
+contains several extra files needed for writing tools.<p>
To check out the code from the CVS repository, first login:
<blockquote><code>
@@ -342,12 +339,12 @@
<code>valgrind/</code>.
<ol>
- <li>Choose a name for the skin, and an abbreviation that can be used as a
+ <li>Choose a name for the tool, and an abbreviation that can be used as a
short prefix. We'll use <code>foobar</code> and <code>fb</code> as an
example.
</li><p>
- <li>Make a new directory <code>foobar/</code> which will hold the skin.
+ <li>Make a new directory <code>foobar/</code> which will hold the tool.
</li><p>
<li>Copy <code>example/Makefile.am</code> into <code>foobar/</code>.
@@ -357,16 +354,16 @@
It might be worth trying to understand this file, at least a little; you
might have to do more complicated things with it later on. In
particular, the name of the <code>vgskin_foobar_so_SOURCES</code> variable
- determines the name of the skin's shared object, which determines what
- name must be passed to the <code>--skin</code> option to use the skin.
+ determines the name of the tool's shared object, which determines what
+ name must be passed to the <code>--tool</code> option to use the tool.
</li><p>
<li>Copy <code>example/ex_main.c</code> into
<code>foobar/</code>, renaming it as <code>fb_main.c</code>.
Edit it by changing the five lines in <code>SK_(pre_clo_init)()</code>
- to something appropriate for the skin. These fields are used in the
+ to something appropriate for the tool. These fields are used in the
startup message, except for <code>bug_reports_to</code> which is used
- if a skin assertion fails.
+ if a tool assertion fails.
</li><p>
<li>Edit <code>Makefile.am</code>, adding the new directory
@@ -384,14 +381,14 @@
make install</pre>
It should automake, configure and compile without errors, putting copies
- of the skin's shared object <code>vgskin_foobar.so</code> in
+ of the tool's shared object <code>vgskin_foobar.so</code> in
<code>foobar/</code> and
<code>inst/lib/valgrind/</code>.
</li><p>
<li>You can test it with a command like
<pre>
- inst/bin/valgrind --skin=foobar date</pre>
+ inst/bin/valgrind --tool=foobar date</pre>
(almost any program should work; <code>date</code> is just an example).
The output should be something like this:
@@ -406,7 +403,7 @@
Wed Sep 25 10:31:54 BST 2002
==738==</pre>
- The skin does nothing except run the program uninstrumented.
+ The tool does nothing except run the program uninstrumented.
</li><p>
</ol>
@@ -414,14 +411,14 @@
for your source files, and use a different <code>--prefix</code> for
<code>./configure</code>.<p>
-Now that we've setup, built and tested the simplest possible skin, onto the
+Now that we've setup, built and tested the simplest possible tool, onto the
interesting stuff...
<a name="writingcode"></a>
<h3>2.6 Writing the code</h3>
-A skin must define at least these four functions:
+A tool must define at least these four functions:
<pre>
SK_(pre_clo_init)()
SK_(post_clo_init)()
@@ -432,34 +429,34 @@
Also, it must use the macro <code>VG_DETERMINE_INTERFACE_VERSION</code>
exactly once in its source code. If it doesn't, you will get a link error
involving <code>VG_(skin_interface_major_version)</code>. This macro is
-used to ensure the core/skin interface used by the core and a plugged-in
-skin are binary compatible.
+used to ensure the core/tool interface used by the core and a plugged-in
+tool are binary compatible.
-In addition, if a skin wants to use some of the optional services provided by
+In addition, if a tool wants to use some of the optional services provided by
the core, it may have to define other functions.
<a name="init"></a>
<h3>2.7 Initialisation</h3>
Most of the initialisation should be done in <code>SK_(pre_clo_init)()</code>.
-Only use <code>SK_(post_clo_init)()</code> if a skin provides command line
+Only use <code>SK_(post_clo_init)()</code> if a tool provides command line
options and must do some initialisation after option processing takes place
(``<code>clo</code>'' stands for ``command line options'').<p>
-First of all, various ``details'' need to be set for a skin, using the
+First of all, various ``details'' need to be set for a tool, using the
functions <code>VG_(details_*)()</code>. Some are all compulsory, some aren't.
Some are used when constructing the startup message,
<code>detail_bug_reports_to</code> is used if <code>VG_(skin_panic)()</code> is
-ever called, or a skin assertion fails. Others have other uses.<p>
+ever called, or a tool assertion fails. Others have other uses.<p>
-Second, various ``needs'' can be set for a skin, using the functions
+Second, various ``needs'' can be set for a tool, using the functions
<code>VG_(needs_*)()</code>. They are mostly booleans, and can be left
-untouched (they default to <code>False</code>). They determine whether a skin
+untouched (they default to <code>False</code>). They determine whether a tool
can do various things such as: record, report and suppress errors; process
command line options; wrap system calls; record extra information about
malloc'd blocks, etc.<p>
-For example, if a skin wants the core's help in recording and reporting errors,
+For example, if a tool wants the core's help in recording and reporting errors,
it must set the <code>skin_errors</code> need to <code>True</code>, and then
provide definitions of six functions for comparing errors, printing out errors,
reading suppressions from a suppressions file, etc. While writing these
@@ -468,14 +465,14 @@
<code>VgNeeds</code> in <code>include/vg_skin.h</code> for full details of all
the needs.<p>
-Third, the skin can indicate which events in core it wants to be notified
+Third, the tool can indicate which events in core it wants to be notified
about, using the functions <code>VG_(track_*)()</code>. These include things
such as blocks of memory being malloc'd, the stack pointer changing, a mutex
-being locked, etc. If a skin wants to know about this, it should set the
+being locked, etc. If a tool wants to know about this, it should set the
relevant pointer in the structure to point to a function, which will be called
when that event happens.<p>
-For example, if the skin want to be notified when a new block of memory is
+For example, if the tool want to be notified when a new block of memory is
malloc'd, it should call <code>VG_(track_new_mem_heap)()</code> with an
appropriate function pointer, and the assigned function will be called each
time this happens.<p>
@@ -489,18 +486,18 @@
<code>SK_(instrument)()</code> is the interesting one. It allows you to
instrument <i>UCode</i>, which is Valgrind's RISC-like intermediate language.
UCode is described in the <a href="mc_techdocs.html">technical docs</a> for
-the Memcheck skin.
+Memcheck.
The easiest way to instrument UCode is to insert calls to C functions when
-interesting things happen. See the skin ``lackey''
+interesting things happen. See the tool ``Lackey''
(<code>lackey/lk_main.c</code>) for a simple example of this, or
Cachegrind (<code>cachegrind/cg_main.c</code>) for a more complex
example.<p>
A much more complicated way to instrument UCode, albeit one that might result
in faster instrumented programs, is to extend UCode with new UCode
-instructions. This is recommended for advanced Valgrind hackers only! See the
-``memcheck'' skin for an example.
+instructions. This is recommended for advanced Valgrind hackers only! See
+Memcheck for an example.
<a name="fini"></a>
<h3>2.9 Finalisation</h3>
@@ -511,45 +508,45 @@
<a name="otherimportantinfo"></a>
<h3>2.10 Other important information</h3>
-Please note that the core/skin split infrastructure is quite complex and
+Please note that the core/tool split infrastructure is quite complex and
not brilliantly documented. Here are some important points, but there are
undoubtedly many others that I should note but haven't thought of.<p>
The file <code>include/vg_skin.h</code> contains all the types,
-macros, functions, etc. that a skin should (hopefully) need, and is the only
-<code>.h</code> file a skin should need to <code>#include</code>.<p>
+macros, functions, etc. that a tool should (hopefully) need, and is the only
+<code>.h</code> file a tool should need to <code>#include</code>.<p>
In particular, you probably shouldn't use anything from the C library (there
are deep reasons for this, trust us). Valgrind provides an implementation of a
reasonable subset of the C library, details of which are in
<code>vg_skin.h</code>.<p>
-Similarly, when writing a skin, you shouldn't need to look at any of the code
+Similarly, when writing a tool, you shouldn't need to look at any of the code
in Valgrind's core. Although it might be useful sometimes to help understand
something.<p>
<code>vg_skin.h</code> has a reasonable amount of documentation in it that
-should hopefully be enough to get you going. But ultimately, the skins
-distributed (memcheck, addrcheck, cachegrind, lackey, etc.) are probably the
+should hopefully be enough to get you going. But ultimately, the tools
+distributed (Memcheck, Addrcheck, Cachegrind, Lackey, etc.) are probably the
best documentation of all, for the moment.<p>
Note that the <code>VG_</code> and <code>SK_</code> macros are used heavily.
These just prepend longer strings in front of names to avoid potential
namespace clashes. We strongly recommend using the <code>SK_</code> macro for
-any global functions and variables in your skin, or writing a similar macro.<p>
+any global functions and variables in your tool, or writing a similar macro.<p>
<a name="wordsofadvice"></a>
<h3>2.11 Words of Advice</h3>
-Writing and debugging skins is not trivial. Here are some suggestions for
+Writing and debugging tools is not trivial. Here are some suggestions for
solving common problems.<p>
-If you are getting segmentation faults in C functions used by your skin, the
+If you are getting segmentation faults in C functions used by your tool, the
usual GDB command:
<blockquote><code>gdb <i>prog</i> core</code></blockquote>
usually gives the location of the segmentation fault.<p>
-If you want to debug C functions used by your skin, you can attach GDB to
+If you want to debug C functions used by your tool, you can attach GDB to
Valgrind with some effort:
<ul>
<li>Enable the following code in <code>coregrind/vg_main.c</code> by
@@ -598,27 +595,27 @@
<a name="advancedtopics"></a>
<h2>3 Advanced Topics</h2>
-Once a skin becomes more complicated, there are some extra things you may
+Once a tool becomes more complicated, there are some extra things you may
want/need to do.
<a name="suppressions"></a>
<h3>3.1 Suppressions</h3>
-If your skin reports errors and you want to suppress some common ones, you can
+If your tool reports errors and you want to suppress some common ones, you can
add suppressions to the suppression files. The relevant files are
<code>valgrind/*.supp</code>; the final suppression file is aggregated from
these files by combining the relevant <code>.supp</code> files depending on the
versions of linux, X and glibc on a system.
<p>
-Suppression types have the form <code>skin_name:suppression_name</code>. The
-<code>skin_name</code> here is the name you specify for the skin during
+Suppression types have the form <code>tool_name:suppression_name</code>. The
+<code>tool_name</code> here is the name you specify for the tool during
initialisation with <code>VG_(details_name)()</code>.
<a name="documentation"></a>
<h3>3.2 Documentation</h3>
If you are feeling conscientious and want to write some HTML documentation for
-your skin, follow these steps (using <code>foobar</code> as the example skin
+your tool, follow these steps (using <code>foobar</code> as the example tool
name again):
<ol>
@@ -645,7 +642,7 @@
<h3>3.3 Regression tests</h3>
Valgrind has some support for regression tests. If you want to write
-regression tests for your skin:
+regression tests for your tool:
<ol>
<li>Make a directory <code>foobar/tests/</code>.
@@ -681,11 +678,11 @@
<a name="profiling"></a>
<h3>3.4 Profiling</h3>
-To do simple tick-based profiling of a skin, include the line
+To do simple tick-based profiling of a tool, include the line
<blockquote>
#include "vg_profile.c"
</blockquote>
-in the skin somewhere, and rebuild (you may have to <code>make clean</code>
+in the tool somewhere, and rebuild (you may have to <code>make clean</code>
first). Then run Valgrind with the <code>--profile=yes</code> option.<p>
The profiler is stack-based; you can register a profiling event with
@@ -693,7 +690,7 @@
<code>VGP_PUSHCC</code> and <code>VGP_POPCC</code> macros to record time spent
doing certain things. New profiling event numbers must not overlap with the
core profiling event numbers. See <code>include/vg_skin.h</code> for details
-and the ``memcheck'' skin for an example.
+and Memcheck for an example.
<a name="othermakefilehackery"></a>
@@ -704,27 +701,27 @@
corresponding entry to the <code>AC_OUTPUT</code> list in
<code>valgrind/configure.in</code>.<p>
-If you add any scripts to your skin (see Cachegrind for an example) you need to
+If you add any scripts to your tool (see Cachegrind for an example) you need to
add them to the <code>bin_SCRIPTS</code> variable in
<code>valgrind/foobar/Makefile.am</code>.<p>
<a name="interfaceversions"></a>
-<h3>3.5 Core/skin interface versions</h3>
+<h3>3.5 Core/tool interface versions</h3>
-In order to allow for the core/skin interface to evolve over time, Valgrind
-uses a basic interface versioning system. All a skin has to do is use the
+In order to allow for the core/tool interface to evolve over time, Valgrind
+uses a basic interface versioning system. All a tool has to do is use the
<code>VG_DETERMINE_INTERFACE_VERSION</code> macro exactly once in its code.
-If not, a link error will occur when the skin is built.
+If not, a link error will occur when the tool is built.
<p>
The interface version number has the form X.Y. Changes in Y indicate binary
compatible changes. Changes in X indicate binary incompatible changes. If
-the core and skin has the same major version number X they should work
+the core and tool has the same major version number X they should work
together. If X doesn't match, Valgrind will abort execution with an
explanation of the problem.
<p>
This approach was chosen so that if the interface changes in the future,
-old skins won't work and the reason will be clearly explained, instead of
+old tools won't work and the reason will be clearly explained, instead of
possibly crashing mysteriously. We have attempted to minimise the potential
for binary incompatible changes by means such as minimising the use of naked
structs in the interface.
@@ -732,14 +729,14 @@
<a name="finalwords"></a>
<h2>4 Final Words</h2>
-This whole core/skin business is still experimental, and under active
-development, although it's slowly maturing.<p>
+This whole core/tool business under active development, although it's slowly
+maturing.<p>
-The first consequence of this is that the core/skin interface will continue
+The first consequence of this is that the core/tool interface will continue
to change in the future; we have no intention of freezing it and then
regretting the inevitable stupidities. Hopefully most of the future changes
will be to add new features, hooks, functions, etc, rather than to change old
-ones, which should cause a minimum of trouble for existing skins, and we've put
+ones, which should cause a minimum of trouble for existing tools, and we've put
some effort into future-proofing the interface to avoid binary incompatibility.
But we can't guarantee anything. The versioning system should catch any
incompatibilities. Just something to be aware of.<p>
@@ -750,10 +747,10 @@
<ul>
<li>If you love it or hate it</li><p>
<li>If you find bugs</li><p>
- <li>If you write a skin</li><p>
+ <li>If you write a tool</li><p>
<li>If you have suggestions for new features, needs, trackable events,
functions</li><p>
- <li>If you have suggestions for making skins easier to write</li><p>
+ <li>If you have suggestions for making tools easier to write</li><p>
<li>If you have suggestions for improving this documentation</li><p>
<li>If you don't understand something</li><p>
</ul>
diff --git a/coregrind/valgrind.in b/coregrind/valgrind.in
index 7907291..71033ec 100755
--- a/coregrind/valgrind.in
+++ b/coregrind/valgrind.in
@@ -42,24 +42,25 @@
# Valgrind options
vgopts=
-# --skin=<foo> arg, specifying skin used
-skin_arg=
+# Tool to use, chosen by --tool=<foo>, defaults to Memcheck
+tool=memcheck
# --in-place=<dir> arg, for using non-installed version
in_place_arg=
-# Default core+skin to use are the installed ones
+# Default core+tool to use are the installed ones
coredir=$VALGRIND
-skindir=$VALGRIND
+tooldir=$VALGRIND
# Collect up args for Valgrind. Only some are intercepted here;
-# the rest are passed to vg_main.c.
+# the rest are passed to vg_main.c. Allow --skin for backwards compatibility.
while [ $# != 0 ]
do
arg=$1
case "$arg" in
--version) echo "valgrind-$version"; exit 1 ;;
- --skin=*) skin_arg=$arg; shift;;
+ --tool=*) tool=`echo $arg | sed 's/--tool=//'`; shift;;
+ --skin=*) tool=`echo $arg | sed 's/--skin=//'`; shift;;
--in-place=*) in_place_arg=$arg; shift;;
-*) vgopts="$vgopts $arg"; shift;;
*) break;;
@@ -67,30 +68,22 @@
done
-# Decide on the skin. Default to memory checking if not specified.
-if [ z"$skin_arg" = z ]; then
- skin=memcheck
-else
- # Hack off the "--skin=" prefix.
- skin=`echo $skin_arg | sed 's/--skin=//'`
-fi
-
# If running uninstalled version in-place...
if [ z"$in_place_arg" != z ]; then
in_place_dir=`echo $in_place_arg | sed 's/--in-place=//'`
- skindir="$in_place_dir/$skin"
+ tooldir="$in_place_dir/$tool"
coredir="$in_place_dir/coregrind/.in_place"
vgsupp="--suppressions=$in_place_dir/default.supp"
fi
-# Setup skin shared object.
-skin_so="vgskin_${skin}.so"
-if [ ! -r "$skindir/$skin_so" ] ; then
+# Setup tool shared object.
+tool_so="vgskin_${tool}.so"
+if [ ! -r "$tooldir/$tool_so" ] ; then
echo
- echo "Skin error:"
- echo " The shared library \`$skin_so' for the chosen"
- echo " skin \`$skin' could not be found in"
- echo " $skindir"
+ echo "Tool error:"
+ echo " The shared library \`$tool_so' for the chosen"
+ echo " tool \`$tool' could not be found in"
+ echo " $tooldir"
echo
exit 1
fi
@@ -155,8 +148,8 @@
LD_LIBRARY_PATH=$coredir:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
-# Insert skin .so before valgrind.so to override template functions.
-LD_PRELOAD=$skindir/$skin_so:$coredir/valgrind.so:$LD_PRELOAD
+# Insert tool .so before valgrind.so to override template functions.
+LD_PRELOAD=$tooldir/$tool_so:$coredir/valgrind.so:$LD_PRELOAD
export LD_PRELOAD
#LD_DEBUG=files
#LD_DEBUG=symbols
diff --git a/coregrind/vg_default.c b/coregrind/vg_default.c
index 5d8043b..b15aef7 100644
--- a/coregrind/vg_default.c
+++ b/coregrind/vg_default.c
@@ -1,6 +1,6 @@
/*--------------------------------------------------------------------*/
-/*--- Default panicky definitions of template functions that skins ---*/
+/*--- Default panicky definitions of template functions that tools ---*/
/*--- should override. ---*/
/*--- vg_defaults.c ---*/
/*--------------------------------------------------------------------*/
@@ -32,49 +32,49 @@
/* These functions aren't intended to be run. Replacement functions used by
- * the chosen skin are substituted by compiling the skin into a .so and
+ * the chosen tool are substituted by compiling the tool into a .so and
* LD_PRELOADing it. Nasty :) */
#include "vg_include.h"
/* ---------------------------------------------------------------------
- Error messages (for malformed skins)
+ Error messages (for malformed tools)
------------------------------------------------------------------ */
-/* If the skin fails to define one or more of the required functions,
+/* If the tool fails to define one or more of the required functions,
* make it very clear what went wrong! */
static __attribute__ ((noreturn))
void fund_panic ( const Char* fn )
{
VG_(printf)(
- "\nSkin error:\n"
- " The skin you have selected is missing the function `%s',\n"
+ "\nTool error:\n"
+ " The tool you have selected is missing the function `%s',\n"
" which is required.\n\n",
fn);
- VG_(skin_panic)("Missing skin function");
+ VG_(skin_panic)("Missing tool function");
}
static __attribute__ ((noreturn))
void non_fund_panic ( const Char* fn )
{
VG_(printf)(
- "\nSkin error:\n"
- " The skin you have selected is missing the function `%s'\n"
+ "\nTool error:\n"
+ " The tool you have selected is missing the function `%s'\n"
" required by one of its needs.\n\n",
fn);
- VG_(skin_panic)("Missing skin function");
+ VG_(skin_panic)("Missing tool function");
}
static __attribute__ ((noreturn))
void malloc_panic ( const Char* fn )
{
VG_(printf)(
- "\nSkin error:\n"
- " The skin you have selected is missing the function `%s'\n"
+ "\nTool error:\n"
+ " The tool you have selected is missing the function `%s'\n"
" required because it is replacing malloc() et al.\n\n",
fn);
- VG_(skin_panic)("Missing skin function");
+ VG_(skin_panic)("Missing tool function");
}
#define FUND(proto) \
@@ -163,11 +163,11 @@
Bool VG_(sk_malloc_called_by_scheduler) = False;
-/* If the skin hasn't replaced malloc(), this one can be called from the
+/* If the tool hasn't replaced malloc(), this one can be called from the
scheduler, for the USERREQ__MALLOC user request used by vg_libpthread.c.
(Nb: it cannot call glibc's malloc().) The lock variable ensures that the
scheduler is the only place this can be called from; this ensures that a
- malloc()-replacing skin cannot forget to implement SK_(malloc)() or
+ malloc()-replacing tool cannot forget to implement SK_(malloc)() or
SK_(free)(). */
__attribute__ ((weak))
void* SK_(malloc)( Int size )
diff --git a/coregrind/vg_dummy_profile.c b/coregrind/vg_dummy_profile.c
index d54204c..3b9a3e4 100644
--- a/coregrind/vg_dummy_profile.c
+++ b/coregrind/vg_dummy_profile.c
@@ -1,6 +1,6 @@
/*--------------------------------------------------------------------*/
-/*--- Dummy profiling machinery -- overridden by skins when they ---*/
+/*--- Dummy profiling machinery -- overridden by tools when they ---*/
/*--- want profiling. ---*/
/*--- vg_dummy_profile.c ---*/
/*--------------------------------------------------------------------*/
@@ -36,9 +36,9 @@
{
VG_(printf)(
"\nProfiling error:\n"
- " The --profile=yes option was specified, but the skin\n"
+ " The --profile=yes option was specified, but the tool\n"
" wasn't built for profiling. #include \"vg_profile.c\"\n"
- " into the skin and rebuild to allow profiling.\n\n");
+ " into the tool and rebuild to allow profiling.\n\n");
VG_(exit)(1);
}
diff --git a/coregrind/vg_errcontext.c b/coregrind/vg_errcontext.c
index 7f4f729..89baa24 100644
--- a/coregrind/vg_errcontext.c
+++ b/coregrind/vg_errcontext.c
@@ -212,7 +212,7 @@
Char* name = SK_(get_error_name)(err);
if (NULL == name) {
VG_(message)(Vg_UserMsg,
- "(skin does not allow error to be suppressed)");
+ "(tool does not allow error to be suppressed)");
return;
}
VG_(printf)(" %s:%s\n", VG_(details).name, name);
diff --git a/coregrind/vg_main.c b/coregrind/vg_main.c
index de67610..edea109 100644
--- a/coregrind/vg_main.c
+++ b/coregrind/vg_main.c
@@ -637,7 +637,7 @@
"usage: valgrind [options] prog-and-args\n"
"\n"
" core user options, with defaults in [ ], are:\n"
-" --skin=<name> main task (skin to use) [Valgrind]\n"
+" --tool=<name> Use the Valgrind tool named <name> [memcheck]\n"
" --help show this message\n"
" --version show version\n"
@@ -674,7 +674,7 @@
" syscall completes [no]\n"
" --assume-2.4=no|yes assume we're running on a 2.4 kernel [no]\n"
"\n"
-" %s skin user options:\n";
+" %s tool user options:\n";
Char* usage2 =
@@ -683,7 +683,7 @@
" --sanity-level=<number> level of sanity checking to do [1]\n"
" --single-step=no|yes translate each instr separately? [no]\n"
" --optimise=no|yes improve intermediate code? [yes]\n"
-" --profile=no|yes profile? (skin must be built for it) [no]\n"
+" --profile=no|yes profile? (tool must be built for it) [no]\n"
" --chain-bb=no|yes do basic-block chaining? [yes]\n"
" --trace-codegen=<XXXXX> show generated code? (X = 0|1) [00000]\n"
" --trace-syscalls=no|yes show all system calls? [no]\n"
@@ -698,7 +698,7 @@
" error context [0=don't show any]\n"
" --wait-for-gdb=yes|no pause on startup to wait for gdb attach\n"
"\n"
-" %s skin debugging options:\n";
+" %s tool debugging options:\n";
Char* usage3 =
"\n"
@@ -708,8 +708,8 @@
" and licensed under the GNU General Public License, version 2.\n"
" Bug reports, feedback, admiration, abuse, etc, to: %s.\n"
"\n"
-" Skins are copyright and licensed by their authors. See each\n"
-" skin's start-up message for more information.\n"
+" Tools are copyright and licensed by their authors. See each\n"
+" tool's start-up message for more information.\n"
"\n";
VG_(printf)(usage1, VG_(details).name);
@@ -1535,9 +1535,9 @@
/* Check skin and core versions are compatible */
if (VG_CORE_INTERFACE_MAJOR_VERSION != VG_(skin_interface_major_version)) {
VG_(printf)("Error:\n"
- " Skin and core interface versions do not match.\n"
+ " Tool and core interface versions do not match.\n"
" Interface version used by core is: %d.%d\n"
- " Interface version used by skin is: %d.%d\n"
+ " Interface version used by tool is: %d.%d\n"
" The major version numbers must match.\n",
VG_CORE_INTERFACE_MAJOR_VERSION,
VG_CORE_INTERFACE_MINOR_VERSION,
diff --git a/coregrind/vg_needs.c b/coregrind/vg_needs.c
index 003d311..551793d 100644
--- a/coregrind/vg_needs.c
+++ b/coregrind/vg_needs.c
@@ -120,7 +120,7 @@
{
#define CHECK_NOT(var, value) \
if ((var)==(value)) { \
- VG_(printf)("\nSkin error: `%s' not initialised\n", \
+ VG_(printf)("\nTool error: `%s' not initialised\n", \
VG__STRING(var)); \
VG_(skin_panic)("Uninitialised details field\n"); \
}
@@ -139,7 +139,7 @@
VG_(track_events).new_mem_stack_32) &&
! VG_(track_events).new_mem_stack)
{
- VG_(printf)("\nSkin error: one of the specialised `new_mem_stack_n'\n"
+ VG_(printf)("\nTool error: one of the specialised `new_mem_stack_n'\n"
"events tracked, but not the generic `new_mem_stack' one.\n");
VG_(skin_panic)("`new_mem_stack' should be defined\n");
}
@@ -151,7 +151,7 @@
VG_(track_events).die_mem_stack_32) &&
! VG_(track_events).die_mem_stack)
{
- VG_(printf)("\nSkin error: one of the specialised `die_mem_stack_n'\n"
+ VG_(printf)("\nTool error: one of the specialised `die_mem_stack_n'\n"
"events tracked, but not the generic `die_mem_stack' one.\n");
VG_(skin_panic)("`die_mem_stack' should be defined\n");
}
@@ -163,7 +163,7 @@
VG_(track_events).post_reg_write_clientcall_return) &&
! VG_(needs).shadow_regs)
{
- VG_(printf)("\nSkin error: one of the `post_reg_write'\n"
+ VG_(printf)("\nTool error: one of the `post_reg_write'\n"
"events tracked, but `shadow_regs' need not set.\n");
VG_(skin_panic)("`shadow_regs' should be set\n");
}
diff --git a/docs/manual.html b/docs/manual.html
index 63e5820..b69a9cf 100644
--- a/docs/manual.html
+++ b/docs/manual.html
@@ -102,11 +102,11 @@
<p>
The following is not part of the user manual. It describes how you can
-write skins for Valgrind, in order to make new program supervision
+write tools for Valgrind, in order to make new program supervision
tools.
-<h4>7 <a href="coregrind_skins.html">
- Valgrind Skins</a></h4>
+<h4>7 <a href="coregrind_tools.html">
+ Valgrind Tools</a></h4>
<p>
The following are not part of the user manual. They describe internal
diff --git a/example/ex_main.c b/example/ex_main.c
index 5e39381..5f103bc 100644
--- a/example/ex_main.c
+++ b/example/ex_main.c
@@ -1,6 +1,6 @@
/*--------------------------------------------------------------------*/
-/*--- An example skin. ex_main.c ---*/
+/*--- An example tool. ex_main.c ---*/
/*--------------------------------------------------------------------*/
#include "vg_skin.h"
@@ -11,7 +11,7 @@
{
VG_(details_name) ("Example");
VG_(details_version) ("0.0.1");
- VG_(details_description) ("an example Valgrind skin");
+ VG_(details_description) ("an example Valgrind tool");
VG_(details_copyright_author)(
"Copyright (C) 2002-2003, and put in the public domain, by Santa Claus.");
VG_(details_bug_reports_to) ("santa.claus@northpole.org");
diff --git a/glibc-2.1.supp b/glibc-2.1.supp
index 64e809b..b318e20 100644
--- a/glibc-2.1.supp
+++ b/glibc-2.1.supp
@@ -5,7 +5,7 @@
# Format of this file is:
# {
# name_of_suppression
-# skin_name:supp_kind
+# tool_name:supp_kind
# (optional extra info for some suppression types)
# caller0 name, or /name/of/so/file.so
# caller1 name, or ditto
diff --git a/glibc-2.2.supp b/glibc-2.2.supp
index 189aa65..afc65c3 100644
--- a/glibc-2.2.supp
+++ b/glibc-2.2.supp
@@ -6,7 +6,7 @@
# Format of this file is:
# {
# name_of_suppression
-# skin_name:supp_kind
+# tool_name:supp_kind
# (optional extra info for some suppression types)
# caller0 name, or /name/of/so/file.so
# caller1 name, or ditto
diff --git a/glibc-2.3.supp b/glibc-2.3.supp
index 702c6b0..72b346a 100644
--- a/glibc-2.3.supp
+++ b/glibc-2.3.supp
@@ -6,7 +6,7 @@
# Format of this file is:
# {
# name_of_suppression
-# skin_name:supp_kind
+# tool_name:supp_kind
# (optional extra info for some suppression types)
# caller0 name, or /name/of/so/file.so
# caller1 name, or ditto
diff --git a/helgrind/docs/hg_main.html b/helgrind/docs/hg_main.html
index 99f56da..74ee451 100644
--- a/helgrind/docs/hg_main.html
+++ b/helgrind/docs/hg_main.html
@@ -7,11 +7,11 @@
<a name="hg-top"></a>
<h2>6 Helgrind: a data-race detector</h2>
-To use this skin, you must specify <code>--skin=helgrind</code> on the
+To use this tool, you must specify <code>--tool=helgrind</code> on the
Valgrind command line.
<p>
-Helgrind is a Valgrind skin for detecting data races in C and C++ programs
+Helgrind is a Valgrind tool for detecting data races in C and C++ programs
that use the Pthreads library.
<p>
It uses the Eraser algorithm described in
@@ -51,7 +51,7 @@
thread with a <code>pthread_join()</code> operation -- they can both access the
same variable without holding a lock.
<p>
-There's a lot of other sophistication in the Helgrind skin, aimed at
+There's a lot of other sophistication in Helgrind, aimed at
reducing the number of false reports, and at producing useful error
reports. We hope to have more documentation one day...
diff --git a/helgrind/helgrind.h b/helgrind/helgrind.h
index 7651b3f..986c8d2 100644
--- a/helgrind/helgrind.h
+++ b/helgrind/helgrind.h
@@ -8,7 +8,7 @@
----------------------------------------------------------------
- This file is part of helgrind, a Valgrind skin for detecting
+ This file is part of helgrind, a Valgrind tool for detecting
data races in threaded programs.
Copyright (C) 2002-2003 Nicholas Nethercote. All rights reserved.
diff --git a/helgrind/hg_main.c b/helgrind/hg_main.c
index 2a2a1c1..c6fddbe 100644
--- a/helgrind/hg_main.c
+++ b/helgrind/hg_main.c
@@ -5,7 +5,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of Helgrind, a Valgrind skin for detecting
+ This file is part of Helgrind, a Valgrind tool for detecting
data races in threaded programs.
Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/lackey/docs/lk_main.html b/lackey/docs/lk_main.html
index bf4fef8..a62ee13 100644
--- a/lackey/docs/lk_main.html
+++ b/lackey/docs/lk_main.html
@@ -35,7 +35,7 @@
<p>
Lackey is licensed under the GNU General Public License,
version 2<br>
-Lackey is an example Valgrind skin that does some very basic program
+Lackey is an example Valgrind tool that does some very basic program
measurement.
</center>
@@ -43,9 +43,9 @@
<h2>1 Lackey</h2>
-Lackey is a simple Valgrind skin that does some basic program measurement.
+Lackey is a simple Valgrind tool that does some basic program measurement.
It adds quite a lot of simple instrumentation to the program's code. It is
-primarily intended to be of use as an example skin.
+primarily intended to be of use as an example tool.
<p>
It measures three things:
diff --git a/lackey/lk_main.c b/lackey/lk_main.c
index bb3aa44..a68841b 100644
--- a/lackey/lk_main.c
+++ b/lackey/lk_main.c
@@ -1,11 +1,11 @@
/*--------------------------------------------------------------------*/
-/*--- Simple skin for counting UInstrs, using a C helper. ---*/
+/*--- Simple tool for counting UInstrs, using a C helper. ---*/
/*--- lk_main.c ---*/
/*--------------------------------------------------------------------*/
/*
- This file is part of Lackey, an example Valgrind skin that does
+ This file is part of Lackey, an example Valgrind tool that does
some simple program measurement.
Copyright (C) 2002-2003 Nicholas Nethercote
@@ -78,7 +78,7 @@
{
VG_(details_name) ("Lackey");
VG_(details_version) (NULL);
- VG_(details_description) ("an example Valgrind skin");
+ VG_(details_description) ("an example Valgrind tool");
VG_(details_copyright_author)(
"Copyright (C) 2002-2003, and GNU GPL'd, by Nicholas Nethercote.");
VG_(details_bug_reports_to) ("njn25@cam.ac.uk");
diff --git a/linux22.supp b/linux22.supp
index 1d56692..98aa7ab 100644
--- a/linux22.supp
+++ b/linux22.supp
@@ -7,7 +7,7 @@
# Format of this file is:
# {
# name_of_suppression
-# skin_name:supp_kind
+# tool_name:supp_kind
# (optional extra info for some suppression types)
# caller0 name, or /name/of/so/file.so
# caller1 name, or ditto
diff --git a/linux24.supp b/linux24.supp
index 58a88f0..c38dbe1 100644
--- a/linux24.supp
+++ b/linux24.supp
@@ -7,7 +7,7 @@
# Format of this file is:
# {
# name_of_suppression
-# skin_name:supp_kind
+# tool_name:supp_kind
# (optional extra info for some suppression types)
# caller0 name, or /name/of/so/file.so
# caller1 name, or ditto
diff --git a/make-uninstall-docs b/make-uninstall-docs
index e7709a9..cc0db79 100755
--- a/make-uninstall-docs
+++ b/make-uninstall-docs
@@ -7,7 +7,7 @@
cp Inst/share/doc/valgrind/coregrind_core.html coregrind/docs
cp Inst/share/doc/valgrind/coregrind_intro.html coregrind/docs
-cp Inst/share/doc/valgrind/coregrind_skins.html coregrind/docs
+cp Inst/share/doc/valgrind/coregrind_tools.html coregrind/docs
cp Inst/share/doc/valgrind/manual.html docs
cp Inst/share/doc/valgrind/ac_main.html addrcheck/docs
cp Inst/share/doc/valgrind/mc_main.html memcheck/docs
diff --git a/memcheck/docs/mc_main.html b/memcheck/docs/mc_main.html
index aedef6e..b827693 100644
--- a/memcheck/docs/mc_main.html
+++ b/memcheck/docs/mc_main.html
@@ -7,13 +7,13 @@
<a name="mc-top"></a>
<h2>3 <b>Memcheck</b>: a heavyweight memory checker</h2>
-To use this skin, you may specify <code>--skin=memcheck</code> on the
+To use this tool, you may specify <code>--tool=memcheck</code> on the
Valgrind command line. But you don't have to, since this is the
-default skin.
+default tool.
<h3>3.1 Kinds of bugs that memcheck can find</h3>
-Memcheck is Valgrind-1.0.X's checking mechanism bundled up into a skin.
+Memcheck is Valgrind-1.0.X's checking mechanism bundled up into a tool.
All reads and writes of memory are checked, and calls to
malloc/new/free/delete are intercepted. As a result, memcheck can
detect the following problems:
@@ -382,7 +382,7 @@
<pre>
Memcheck:suppression_type
</pre>
-Or, since some of the suppressions are shared with the Addrcheck skin:
+Or, since some of the suppressions are shared with Addrcheck:
<pre>
Memcheck,Addrcheck:suppression_type
</pre>
@@ -772,7 +772,7 @@
<h3>3.7 Client Requests</h3>
The following client requests are defined in <code>memcheck.h</code>. They
-also work for the Addrcheck skin. See <code>memcheck.h</code> for exact
+also work for Addrcheck. See <code>memcheck.h</code> for exact
details of their arguments.
<ul>
diff --git a/memcheck/mac_leakcheck.c b/memcheck/mac_leakcheck.c
index a9b5ad2..5084075 100644
--- a/memcheck/mac_leakcheck.c
+++ b/memcheck/mac_leakcheck.c
@@ -5,8 +5,8 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
- detecting memory errors, and AddrCheck, a lightweight Valgrind skin
+ This file is part of MemCheck, a heavyweight Valgrind tool for
+ detecting memory errors, and AddrCheck, a lightweight Valgrind tool
for detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mac_malloc_wrappers.c b/memcheck/mac_malloc_wrappers.c
index 536cc2e..c9b2fca 100644
--- a/memcheck/mac_malloc_wrappers.c
+++ b/memcheck/mac_malloc_wrappers.c
@@ -5,8 +5,8 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
- detecting memory errors, and AddrCheck, a lightweight Valgrind skin
+ This file is part of MemCheck, a heavyweight Valgrind tool for
+ detecting memory errors, and AddrCheck, a lightweight Valgrind tool
for detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mac_needs.c b/memcheck/mac_needs.c
index 1fd0ef7..f90efb0 100644
--- a/memcheck/mac_needs.c
+++ b/memcheck/mac_needs.c
@@ -5,8 +5,8 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
- detecting memory errors, and AddrCheck, a lightweight Valgrind skin
+ This file is part of MemCheck, a heavyweight Valgrind tool for
+ detecting memory errors, and AddrCheck, a lightweight Valgrind tool
for detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mac_replace_strmem.c b/memcheck/mac_replace_strmem.c
index 06e6a57..6ae5800 100644
--- a/memcheck/mac_replace_strmem.c
+++ b/memcheck/mac_replace_strmem.c
@@ -6,7 +6,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mac_shared.h b/memcheck/mac_shared.h
index 3550ce8..70fbab1 100644
--- a/memcheck/mac_shared.h
+++ b/memcheck/mac_shared.h
@@ -5,8 +5,8 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
- detecting memory errors, and AddrCheck, a lightweight Valgrind skin
+ This file is part of MemCheck, a heavyweight Valgrind tool for
+ detecting memory errors, and AddrCheck, a lightweight Valgrind tool
for detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mc_clientreqs.c b/memcheck/mc_clientreqs.c
index 56d1773..ddfb05d 100644
--- a/memcheck/mc_clientreqs.c
+++ b/memcheck/mc_clientreqs.c
@@ -6,7 +6,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mc_constants.h b/memcheck/mc_constants.h
index 455175d..48f8509 100644
--- a/memcheck/mc_constants.h
+++ b/memcheck/mc_constants.h
@@ -4,7 +4,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mc_errcontext.c b/memcheck/mc_errcontext.c
index 1360dbe..5542581 100644
--- a/memcheck/mc_errcontext.c
+++ b/memcheck/mc_errcontext.c
@@ -5,7 +5,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mc_from_ucode.c b/memcheck/mc_from_ucode.c
index dbf1747..e1f2877 100644
--- a/memcheck/mc_from_ucode.c
+++ b/memcheck/mc_from_ucode.c
@@ -1,11 +1,11 @@
/*--------------------------------------------------------------------*/
-/*--- Generate code for skin-specific UInstrs. ---*/
+/*--- Generate code for tool-specific UInstrs. ---*/
/*--- mc_from_ucode.c ---*/
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mc_helpers.S b/memcheck/mc_helpers.S
index 681f049..f8ed6dc 100644
--- a/memcheck/mc_helpers.S
+++ b/memcheck/mc_helpers.S
@@ -5,7 +5,7 @@
##--------------------------------------------------------------------##
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mc_include.h b/memcheck/mc_include.h
index 01414e2..69e1d6d 100644
--- a/memcheck/mc_include.h
+++ b/memcheck/mc_include.h
@@ -1,11 +1,11 @@
/*--------------------------------------------------------------------*/
-/*--- A header file for all parts of the MemCheck skin. ---*/
+/*--- A header file for all parts of the MemCheck tool. ---*/
/*--- mc_include.h ---*/
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mc_main.c b/memcheck/mc_main.c
index 9e82f39..52ad032 100644
--- a/memcheck/mc_main.c
+++ b/memcheck/mc_main.c
@@ -6,7 +6,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/mc_translate.c b/memcheck/mc_translate.c
index e88f442..249076c 100644
--- a/memcheck/mc_translate.c
+++ b/memcheck/mc_translate.c
@@ -5,7 +5,7 @@
/*--------------------------------------------------------------------*/
/*
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2000-2003 Julian Seward
diff --git a/memcheck/memcheck.h b/memcheck/memcheck.h
index 5db9900..5dc7c80 100644
--- a/memcheck/memcheck.h
+++ b/memcheck/memcheck.h
@@ -9,7 +9,7 @@
----------------------------------------------------------------
- This file is part of MemCheck, a heavyweight Valgrind skin for
+ This file is part of MemCheck, a heavyweight Valgrind tool for
detecting memory errors.
Copyright (C) 2002-2003 Julian Seward. All rights reserved.
diff --git a/none/docs/nl_main.html b/none/docs/nl_main.html
index c72ba6a..fc6996e 100644
--- a/none/docs/nl_main.html
+++ b/none/docs/nl_main.html
@@ -35,21 +35,21 @@
<p>
Nulgrind is licensed under the GNU General Public License,
version 2<br>
-Nulgrind is a Valgrind skin that does not very much at all.
+Nulgrind is a Valgrind tool that does not very much at all.
</center>
<p>
<h2>1 Nulgrind</h2>
-Nulgrind is the minimal skin for Valgrind. It does no initialisation or
+Nulgrind is the minimal tool for Valgrind. It does no initialisation or
finalisation, and adds no instrumentation to the program's code. It is mainly
of use for Valgrind's developers for debugging and regression testing.
<p>
Nonetheless you can run programs with Nulgrind. They will run roughly 5-10
times more slowly than normal, for no useful effect. Note that you need to use
-the option <code>--skin=none</code> to run Nulgrind (ie. not
-<code>--skin=nulgrind</code>).
+the option <code>--tool=none</code> to run Nulgrind (ie. not
+<code>--tool=nulgrind</code>).
<hr width="100%">
</body>
diff --git a/none/nl_main.c b/none/nl_main.c
index a7283dc..ee2edb7 100644
--- a/none/nl_main.c
+++ b/none/nl_main.c
@@ -1,10 +1,10 @@
/*--------------------------------------------------------------------*/
-/*--- Nulgrind: The null skin. nl_main.c ---*/
+/*--- Nulgrind: The null tool. nl_main.c ---*/
/*--------------------------------------------------------------------*/
/*
- This file is part of Nulgrind, the simplest possible Valgrind skin,
+ This file is part of Nulgrind, the simplest possible Valgrind tool,
which does nothing.
Copyright (C) 2002-2003 Nicholas Nethercote
diff --git a/tests/vg_regtest.in b/tests/vg_regtest.in
index 18e3693..831cf7b 100755
--- a/tests/vg_regtest.in
+++ b/tests/vg_regtest.in
@@ -60,8 +60,8 @@
# If results don't match, the output can be found in <test>.std<strm>.out,
# and the diff between expected and actual in <test>.std<strm>.diff.
#
-# Notes on adding regression tests for a new skin are in
-# coregrind/docs/skins.html.
+# Notes on adding regression tests for a new tool are in
+# coregrind/docs/coregrind_tools.html.
#----------------------------------------------------------------------------
use warnings;
@@ -205,11 +205,11 @@
(system($_[0]) != 2) or exit 1; # 2 is SIGINT
}
-# from a directory name like "/foo/cachesim/tests/" determine the skin name
-sub determine_skin()
+# from a directory name like "/foo/cachesim/tests/" determine the tool name
+sub determine_tool()
{
my $dir = `pwd`;
- $dir =~ /.*\/([^\/]+)\/tests.*/; # foo/skin_name/tests/foo
+ $dir =~ /.*\/([^\/]+)\/tests.*/; # foo/tool_name/tests/foo
return $1;
}
@@ -224,12 +224,12 @@
printf("%-16s valgrind $vgopts $prog $args\n", "$name:");
- # Pass the appropriate --skin option for the directory (can be overridden
+ # Pass the appropriate --tool option for the directory (can be overridden
# by an "args:" or "args.dev:" line, though).
# Also, because the default valgrind is coregrind/valgrind which isn't
# executable, prepend `sh'.
- my $skin=determine_skin();
- mysystem("sh $valgrind --skin=$skin --in-place=$tests_dir $vgopts $prog $args > $name.stdout.out 2> $name.stderr.out");
+ my $tool=determine_tool();
+ mysystem("sh $valgrind --tool=$tool --in-place=$tests_dir $vgopts $prog $args > $name.stdout.out 2> $name.stderr.out");
if (defined $stdout_filter) {
mysystem("$stdout_filter < $name.stdout.out > $tmp");
diff --git a/xfree-3.supp b/xfree-3.supp
index 178f9ce..c3af0b8 100644
--- a/xfree-3.supp
+++ b/xfree-3.supp
@@ -6,7 +6,7 @@
# Format of this file is:
# {
# name_of_suppression
-# skin_name:supp_kind
+# tool_name:supp_kind
# (optional extra info for some suppression types)
# caller0 name, or /name/of/so/file.so
# caller1 name, or ditto
diff --git a/xfree-4.supp b/xfree-4.supp
index e71c78c..d0502c0 100644
--- a/xfree-4.supp
+++ b/xfree-4.supp
@@ -6,7 +6,7 @@
# Format of this file is:
# {
# name_of_suppression
-# skin_name:supp_kind
+# tool_name:supp_kind
# (optional extra info for some suppression types)
# caller0 name, or /name/of/so/file.so
# caller1 name, or ditto