📄 writing-tools.html
字号:
<html xmlns:cf="http://docbook.sourceforge.net/xmlns/chunkfast/1.0"><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>4.燱riting a New Valgrind Tool</title><link rel="stylesheet" href="vg_basic.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.0"><link rel="start" href="index.html" title="Valgrind Documentation"><link rel="up" href="tech-docs.html" title="Valgrind Technical Documentation"><link rel="prev" href="cl-format.html" title="3.燙allgrind Format Specification"><link rel="next" href="dist.html" title="Valgrind Distribution Documents"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div><table class="nav" width="100%" cellspacing="3" cellpadding="3" border="0" summary="Navigation header"><tr><td width="22px" align="center" valign="middle"><a accesskey="p" href="cl-format.html"><img src="images/prev.png" width="18" height="21" border="0" alt="Prev"></a></td><td width="25px" align="center" valign="middle"><a accesskey="u" href="tech-docs.html"><img src="images/up.png" width="21" height="18" border="0" alt="Up"></a></td><td width="31px" align="center" valign="middle"><a accesskey="h" href="index.html"><img src="images/home.png" width="27" height="20" border="0" alt="Up"></a></td><th align="center" valign="middle">Valgrind Technical Documentation</th><td width="22px" align="center" valign="middle"><a accesskey="n" href="dist.html"><img src="images/next.png" width="18" height="21" border="0" alt="Next"></a></td></tr></table></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="writing-tools"></a>4.燱riting a New Valgrind Tool</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="writing-tools.html#writing-tools.intro">4.1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="writing-tools.html#writing-tools.supexec">4.1.1. Supervised Execution</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.tools">4.1.2. Tools</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.execspaces">4.1.3. Execution Spaces</a></span></dt></dl></dd><dt><span class="sect1"><a href="writing-tools.html#writing-tools.writingatool">4.2. Writing a Tool</a></span></dt><dd><dl><dt><span class="sect2"><a href="writing-tools.html#writing-tools.whywriteatool">4.2.1. Why write a tool?</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.suggestedtools">4.2.2. Suggested tools</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.howtoolswork">4.2.3. How tools work</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.gettingcode">4.2.4. Getting the code</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.gettingstarted">4.2.5. Getting started</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.writingcode">4.2.6. Writing the code</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.init">4.2.7. Initialisation</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.instr">4.2.8. Instrumentation</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.fini">4.2.9. Finalisation</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.otherinfo">4.2.10. Other Important Information</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.advice">4.2.11. Words of Advice</a></span></dt></dl></dd><dt><span class="sect1"><a href="writing-tools.html#writing-tools.advtopics">4.3. Advanced Topics</a></span></dt><dd><dl><dt><span class="sect2"><a href="writing-tools.html#writing-tools.suppressions">4.3.1. Suppressions</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.docs">4.3.2. Documentation</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.regtests">4.3.3. Regression Tests</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.profiling">4.3.4. Profiling</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.mkhackery">4.3.5. Other Makefile Hackery</a></span></dt><dt><span class="sect2"><a href="writing-tools.html#writing-tools.ifacever">4.3.6. Core/tool Interface Versions</a></span></dt></dl></dd><dt><span class="sect1"><a href="writing-tools.html#writing-tools.finalwords">4.4. Final Words</a></span></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="writing-tools.intro"></a>4.1.營ntroduction</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="writing-tools.supexec"></a>4.1.1.燬upervised Execution</h3></div></div></div><p>Valgrind provides a generic infrastructure for supervisingthe execution of programs. This is done by providing a way toinstrument programs in very precise ways, making it relativelyeasy to support activities such as dynamic error detection andprofiling.</p><p>Although writing a tool is not easy, and requires learningquite a few things about Valgrind, it is much easier thaninstrumenting a program from scratch yourself.</p><p>[Nb: What follows is slightly out of date.]</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="writing-tools.tools"></a>4.1.2.燭ools</h3></div></div></div><p>The key idea behind Valgrind's architecture is the divisionbetween its "core" and "tools".</p><p>The core provides the common low-level infrastructure tosupport program instrumentation, including the JITcompiler, low-level memory manager, signal handling and ascheduler (for pthreads). It also provides certain services thatare useful to some but not all tools, such as support for errorrecording and suppression.</p><p>But the core leaves certain operations undefined, whichmust be filled by tools. Most notably, tools define how programcode should be instrumented. They can also call certainfunctions to indicate to the core that they would like to usecertain services, or be notified when certain interesting eventsoccur. But the core takes care of all the hard work.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="writing-tools.execspaces"></a>4.1.3.燛xecution Spaces</h3></div></div></div><p>An important concept to understand before writing a tool isthat there are three spaces in which program code executes:</p><div class="orderedlist"><ol type="1"><li><p>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><p>Code executed in user space includes all the program code, almost all of the C library (including things like the dynamic linker), and almost all parts of all other libraries.</p></li><li><p>Core space: a small proportion of the program's execution takes place entirely within Valgrind's core. This includes:</p><div class="itemizedlist"><ul type="disc"><li><p>Dynamic memory management (<code class="computeroutput">malloc()</code> etc.)</p></li><li><p>Thread scheduling</p></li><li><p>Signal handling</p></li></ul></div><p>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 tool can be notified when certain interesting events happen, for example when dynamic memory is allocated or freed, the stack pointer is changed, or a pthread mutex is locked, etc.</p><p>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 tool is not notified of this, because it's not directly part of the supervised program's execution.</p></li><li><p>Kernel space: execution in the kernel. Two kinds:</p><div class="orderedlist"><ol type="a"><li><p>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 tool to wrap system calls.</p></li><li><p>Other: all other kernel activity (e.g. process scheduling) is totally opaque and irrelevant to the program.</p></li></ol></div></li><li><p>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 tool won't be totally accurate.</p></li></ol></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="writing-tools.writingatool"></a>4.2.燱riting a Tool</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="writing-tools.whywriteatool"></a>4.2.1.燱hy write a tool?</h3></div></div></div><p>Before you write a tool, you should have some idea of whatit should do. What is it you want to know about your programs ofinterest? Consider some existing tools:</p><div class="itemizedlist"><ul type="disc"><li><p><span><strong class="command">memcheck</strong></span>: among other things, performs fine-grained validity and addressibility checks of every memory reference performed by the program.</p></li><li><p><span><strong class="command">cachegrind</strong></span>: tracks every instruction and memory reference to simulate instruction and data caches, tracking cache accesses and misses that occur on every line in the program.</p></li><li><p><span><strong class="command">helgrind</strong></span>: tracks every memory access and mutex lock/unlock to determine if a program contains any data races.</p></li><li><p><span><strong class="command">lackey</strong></span>: does simple counting of various things: the number of calls to a particular function (<code class="computeroutput">_dl_runtime_resolve()</code>); the number of basic blocks, guest instructions, VEX instructions executed; the number of branches executed and the proportion of them which were taken.</p></li></ul></div><p>These examples give a reasonable idea of what kinds ofthings Valgrind can be used for. The instrumentation can rangefrom very lightweight (e.g. counting the number of times aparticular function is called) to very intrusive (e.g.memcheck's memory checking).</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="writing-tools.suggestedtools"></a>4.2.2.燬uggested tools</h3></div></div></div><p>Here is a list of ideas we have had for tools that shouldnot be too hard to implement.</p><div class="itemizedlist"><ul type="disc"><li><p><span><strong class="command">branch profiler</strong></span>: A machine's branch prediction hardware could be simulated, and each branch annotated with the number of predicted and mispredicted branches. Would be implemented quite similarly to Cachegrind, and could reuse the <code class="computeroutput">cg_annotate</code> script to annotate source code.</p><p>The biggest difficulty with this is the simulation; the chip-makers are very cagey about how their chips do branch prediction. But implementing one or more of the basic algorithms could still give good information.</p></li><li><p><span><strong class="command">coverage tool</strong></span>: Cachegrind can already be used for doing test coverage, but it's massive overkill to use it just for that.</p><p>It would be easy to write a coverage tool that records how many times each basic block was recorded. Again, the <code class="computeroutput">cg_annotate</code> script could be used for annotating source code with the gathered information. Although, <code class="computeroutput">cg_annotate</code> is only designed for working with single program runs. It could be extended relatively easily to deal with multiple runs of a program, so that the coverage of a whole test suite could be determined.</p><p>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 tool could record all inputs to the conditional test, and print these out when annotating.</p></li><li><p><span><strong class="command">run-time type checking</strong></span>: A nice example of a dynamic checker is given in this paper:</p><div class="address"><p>Debugging爒ia燫un-Time燭ype燙hecking<br>牋Alexey燣oginov,燬uan燞si燳ong,燬usan燞orwitz燼nd燭homas燫eps<br>牋Proceedings爋f燜undamental燗pproaches爐o燬oftware燛ngineering<br>牋April⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -