From: Nicholas Nethercote Date: Tue, 20 May 2003 17:32:21 +0000 (+0000) Subject: Minor docs fixups. X-Git-Tag: svn/VALGRIND_2_0_0~140 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=c4e8c61d5adfec6100ac74a3c49265f27ba8dbc4;p=thirdparty%2Fvalgrind.git Minor docs fixups. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1644 --- diff --git a/coregrind/docs/coregrind_skins.html b/coregrind/docs/coregrind_skins.html index 7123db19e1..18f17679c6 100644 --- a/coregrind/docs/coregrind_skins.html +++ b/coregrind/docs/coregrind_skins.html @@ -251,17 +251,22 @@ implement.
Debugging via Run-Time Type Checking
Alexey Loginov, Suan Hsi Yong, Susan Horwitz and Thomas Reps
- Proceedings of Proceedings of Fundamental Approaches to Software - Engineering
+ Proceedings of Fundamental Approaches to Software Engineering
April 2001.
- This approach can find quite a range of bugs in C and C++ programs.

+ Similar is the tool described in this paper: - This could be implemented quite nicely as a Valgrind skin. One - complication is that the described tool works directly on C code, and - Valgrind skins work on UCode, but the approach can hopefully still be - used with only minor modifications.

+

+ Run-Time Type Checking for Binary Programs
+ Michael Burrows, Stephen N. Freund, Janet L. Wiener
+ Proceedings of the 12th International Conference on Compiler Construction + (CC 2003)
+ April 2003. +
+ + 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.

Ways to speed up this run-time type checking are described in this paper: @@ -483,7 +488,8 @@ found in include/vg_skin.h.

SK_(instrument)() is the interesting one. It allows you to instrument UCode, which is Valgrind's RISC-like intermediate language. -UCode is described in the technical docs. +UCode is described in the technical docs for +the Memcheck skin. The easiest way to instrument UCode is to insert calls to C functions when interesting things happen. See the skin ``lackey'' @@ -505,8 +511,8 @@ information collected. Any log files should be written out at this point.

2.10  Other important information

-Please note that the core/skin split infrastructure is all very new, and not -very well documented. Here are some important points, but there are +Please note that the core/skin 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.

The file include/vg_skin.h contains all the types, @@ -529,8 +535,8 @@ best documentation of all, for the moment.

Note that the VG_ and SK_ macros are used heavily. These just prepend longer strings in front of names to avoid potential -namespace clashes. We strongly recommend using the SK_ macro -for any global functions and variables in your skin.

+namespace clashes. We strongly recommend using the SK_ macro for +any global functions and variables in your skin, or writing a similar macro.

2.11  Words of Advice

@@ -603,6 +609,10 @@ add suppressions to the suppression files. The relevant files are valgrind/*.supp; the final suppression file is aggregated from these files by combining the relevant .supp files depending on the versions of linux, X and glibc on a system. +

+Suppression types have the form skin_name:suppression_name. The +skin_name here is the name you specify for the skin during +initialisation with VG_(details_name)().

3.2  Documentation

@@ -625,15 +635,9 @@ name again):
  • Write foobar/docs/Makefile.am. Use memcheck/docs/Makefile.am as an example. -
    • - -
  • Write the documentation; the top-level file should be called - foobar/docs/index.html.

    • -

  • (optional) Add a link in the main documentation index - docs/index.html to - foobar/docs/index.html +
  • Write the documentation, putting it in foobar/docs/.

    • @@ -728,18 +732,17 @@ structs in the interface.

    4  Final Words

    -This whole core/skin business is very new and experimental, and under active -development.

    - -The first consequence of this is that the core/skin interface is quite -immature. It will almost certainly 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 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.

    +This whole core/skin business is still experimental, and under active +development, although it's slowly maturing.

    + +The first consequence of this is that the core/skin 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 +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.

    The second consequence of this is that we'd love to hear your feedback about it: