121 lines
11 KiB
HTML
121 lines
11 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 5: 2000</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume5.html" title="Volume 5: 2000" /><link rel="prev" href="Issue5-13.html" title="Issue 5-13, March 29, 2000" /><link rel="next" href="Issue5-15.html" title="Issue 5-15, April 12, 2000" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue5-13.html" title="Issue 5-13, March 29, 2000"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume5.html" title="Volume 5: 2000"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue5-15.html" title="Issue 5-15, April 12, 2000"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 5: 2000</div></div><div id="headerB">Prev: <a href="Issue5-13.html">Issue 5-13, March 29, 2000</a> Up: <a href="volume5.html">Volume 5: 2000</a> Next: <a href="Issue5-15.html">Issue 5-15, April 12, 2000</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue5-14"></a>Issue 5-14, April 5, 2000</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering5-14"></a>Be Engineering Insights: Watch Your Data!</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">John</span> <span class="surname">Dance</span></span></div></div></div><p>
|
||
Every successful programmer carries around a bag of tips and techniques.
|
||
Today, I'll offer a few on the watchpoint.
|
||
</p><p>
|
||
Ever had the value of a variable go bad on you? Sometime between the
|
||
initialization or critical assignment of that variable and a subsequent
|
||
use, the value has changed. So—what technique do you use to figure out
|
||
how or when it changed?
|
||
</p><p>
|
||
If you're dealing with a big body of code you didn't write (or wrote a
|
||
few months ago), you probably first search through the code to find all
|
||
the uses of that item: where it's used, and especially where it's set.
|
||
Another technique is to print out the value of that variable at various
|
||
points in your program. Many programmers perform a binary search by
|
||
narrowing the printouts until they find the area where the data changed.
|
||
Both methods can be useful, but they can also waste a lot of time.
|
||
</p><p>
|
||
A watchpoint is a debugger monitor that you can put on a data address, to
|
||
act as a "data breakpoint." As soon as the value at that address changes,
|
||
the debugger stops the running program and reports where it changed. If
|
||
the hardware doesn't support watchpoints, the debugger must resort to
|
||
tricks like single stepping the program and checking the value after each
|
||
step. As you can imagine, this really slows down program execution.
|
||
However, if the hardware supports watchpoints, the debugger just has to
|
||
set up the appropriate state and instruct the hardware to do the
|
||
watching. Then the program can run happily at full speed. This is how bdb
|
||
works on the x86 architecture.
|
||
</p><p>
|
||
Here's an example that explains how watchpoints work, based on a piece of
|
||
nonsense code with a bug in it.
|
||
</p><pre class="programlisting c">
|
||
#include <stdio.h>
|
||
#include <iostream.h>
|
||
|
||
<span class="type">const short</span> <code class="varname">kNumHexChars</code> = 16;
|
||
<span class="type">const char*</span> <code class="varname">kGreeting</code> = "Hello World...\n";
|
||
<span class="type">const char*</span> <code class="varname">kGoodbye</code> = "Goodbye for now\n";
|
||
|
||
<span class="type">int</span> main()
|
||
{
|
||
<span class="comment">// line 10</span>
|
||
<span class="type">int</span> <code class="varname">oneHexNumber</code>;
|
||
<span class="type">char</span> <code class="varname">hexChars</code>[<code class="varname">kNumHexChars</code>];
|
||
<span class="type">int</span> <code class="varname">anotherHexNumber</code>;
|
||
|
||
<span class="comment">// line 15</span>
|
||
<code class="varname">oneHexNumber</code> = 0xff;
|
||
<code class="varname">anotherHexNumber</code> = 0x100;
|
||
<span class="type">char*</span> <code class="varname">hello</code> = new <span class="type">char</span>[strlen(<code class="varname">kGreeting</code>)];
|
||
<span class="type">char*</span> <code class="varname">goodbye</code> = new <span class="type">char</span>[strlen(<code class="varname">kGoodbye</code>)];
|
||
|
||
<span class="comment">// line 20</span>
|
||
<code class="function">strcpy</code>(<code class="varname">hello</code>, <code class="varname">kGreeting</code>);
|
||
<code class="function">strcpy</code>(<code class="varname">goodbye</code>, <code class="varname">kGoodbye</code>);
|
||
<code class="varname">cerr</code> << <code class="varname">hello</code>;
|
||
|
||
<span class="comment">// line 25</span>
|
||
for (<span class="type">int</span> <code class="varname">i</code> = 0; <code class="varname">i</code> <= <code class="varname">kNumHexChars</code>; <code class="varname">i</code>++) {
|
||
<code class="varname">hexChars</code>[<code class="varname">i</code>] = (<code class="varname">i</code> < 10) ? ('0' + <code class="varname">i</code>) : ('A' + (<code class="varname">i</code>-10));
|
||
}
|
||
|
||
<span class="comment">// line 30</span>
|
||
<code class="varname">cerr</code> << "Our two numbers are " << <code class="varname">oneHexNumber</code>
|
||
<< " and " << <code class="varname">anotherHexNumber</code> << "\n";
|
||
<code class="varname">cerr</code> << <code class="varname">goodbye</code>;
|
||
return 0;
|
||
}
|
||
</pre><p>
|
||
If I run this program, the output is
|
||
</p><pre class="screen">
|
||
Hello World...
|
||
Our two numbers are 71 and 256
|
||
Goodbye for now
|
||
</pre><p>
|
||
Wait a minute! The first number should be 255, not 71. What happened to
|
||
it? Sometime between when its value was assigned (line 16) and when it
|
||
was used (line 31) the value has changed.
|
||
</p><p>
|
||
Of course, this example is trivial, but there can often be hundreds or
|
||
thousands of lines executed between the initialization or assignment and
|
||
a subsequent usage. Even if this program were thousands of lines long,
|
||
solving this problem is trivial with a watchpoint. Just use bdb to step
|
||
to line 17 in the program and select "oneHexNumber" in the variables
|
||
view. Then choose Data->Add Watchpoint, and continue running the program.
|
||
</p><p>
|
||
<span class="application">bdb</span> stops with an alert "Watchpoint Hit: Watchpoint 1 at address
|
||
0xfd001bf0 written". The <code class="literal">pc</code> in <span class="application">bdb</span>
|
||
is at line 29. I look at the state of
|
||
the program and find that the variable <code class="varname">i</code> is 16. My loop test should have
|
||
been <code class="code"><code class="varname">i</code> < <code class="constant">kNumberHexChars</code></code>.
|
||
I overstepped the array and trampled on
|
||
<code class="varname">oneHexNumber</code>. Now I fix the program and continue on a happy man.
|
||
(Actually I don't in this case because there are two other types of bugs
|
||
lurking in this code waiting to bite me. Four lines of code must be
|
||
changed. Can you find them? Watchpoints don't help in this case—so
|
||
what does?
|
||
</p><p>
|
||
Some things to remember about watchpoints and their current
|
||
implementation in bdb:
|
||
</p><div class="orderedlist"><ol><li><p>
|
||
While the x86 architecture itself supports four hardware
|
||
breakpoints, <span class="application">bdb</span> is limited to three watchpoints.
|
||
</p></li><li><p>
|
||
The range of watchpoints is currently 4 bytes (long word aligned),
|
||
so if you're watching a <span class="type">char</span>, you'll be stopped for changes to the
|
||
memory addresses surrounding that char also. Just use the address
|
||
given in the alert and the memory viewer to find out if your char was
|
||
changed in these cases.
|
||
</p></li><li><p>
|
||
You can set watchpoints on variables in the variable view, or on
|
||
addresses in the register window, or on memory locations in the memory
|
||
viewer, or on manually entered addresses in
|
||
<span class="guimenu">Window</span>-><span class="guimenuitem">Set Watchpoint</span>.
|
||
</p></li></ol></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue5-13.html">Issue 5-13, March 29, 2000</a> Up: <a href="volume5.html">Volume 5: 2000</a> Next: <a href="Issue5-15.html">Issue 5-15, April 12, 2000</a> </div><div id="footerB"><div id="footerBL"><a href="Issue5-13.html" title="Issue 5-13, March 29, 2000"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume5.html" title="Volume 5: 2000"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue5-15.html" title="Issue 5-15, April 12, 2000"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|