deploy: 7482a63

ch03-04-debugging-programs.html

@@ -200,7 +200,7 @@ <h2><a class="header" href="#attaching-to-the-debugger-renode" id="attaching-to-
 </code></pre>
 <p>On Renode, port <code>3333</code> also exists, but it is useful mainly for debugging machine mode, i.e., when the hardware is in the loader or inside the kernel only.</p>
 <ul>
-<li><code>3333</code> is useful for when Xous itself has crashed, or when you're debugging the bootloader and Xous isn't even running. It's a stop-the-world debugger. Like &quot;God Mode&quot; on the Vex, where you really can do anything. Debugging there has no effect on the emulated world, so it's like stopping time and looking at things.</li>
+<li><code>3333</code> is useful for when Xous itself has crashed, or when you're debugging the bootloader and Xous isn't even running. It's a stop-the-world debugger. Like &quot;God Mode&quot; on the Vex, where you really can do anything. Debugging there has no effect on the emulated world, so it's like stopping time and looking at things. This port also has no concept of processes or threads, so what process you're in is arbitrary every time you pause the debugger.</li>
 <li><code>3456</code> is identical to what is presented on the hardware serial port (see next section). It's invasive, since processes will keep running when you attach but their timing will be skewed. It does, however, let you attach to a given process and get actual translated memory pages. With 3333 you kind of just hope that you don't have to deal with any MMU pages in a process, which is a nonissue as long as you're just debugging the kernel or bootloader.</li>
 </ul>
 <h2><a class="header" href="#attaching-to-the-debugger-hardware" id="attaching-to-the-debugger-hardware">Attaching to the debugger (Hardware)</a></h2>

print.html

@@ -724,7 +724,7 @@ <h2><a class="header" href="#attaching-to-the-debugger-renode" id="attaching-to-
 </code></pre>
 <p>On Renode, port <code>3333</code> also exists, but it is useful mainly for debugging machine mode, i.e., when the hardware is in the loader or inside the kernel only.</p>
 <ul>
-<li><code>3333</code> is useful for when Xous itself has crashed, or when you're debugging the bootloader and Xous isn't even running. It's a stop-the-world debugger. Like &quot;God Mode&quot; on the Vex, where you really can do anything. Debugging there has no effect on the emulated world, so it's like stopping time and looking at things.</li>
+<li><code>3333</code> is useful for when Xous itself has crashed, or when you're debugging the bootloader and Xous isn't even running. It's a stop-the-world debugger. Like &quot;God Mode&quot; on the Vex, where you really can do anything. Debugging there has no effect on the emulated world, so it's like stopping time and looking at things. This port also has no concept of processes or threads, so what process you're in is arbitrary every time you pause the debugger.</li>
 <li><code>3456</code> is identical to what is presented on the hardware serial port (see next section). It's invasive, since processes will keep running when you attach but their timing will be skewed. It does, however, let you attach to a given process and get actual translated memory pages. With 3333 you kind of just hope that you don't have to deal with any MMU pages in a process, which is a nonissue as long as you're just debugging the kernel or bootloader.</li>
 </ul>
 <h2><a class="header" href="#attaching-to-the-debugger-hardware" id="attaching-to-the-debugger-hardware">Attaching to the debugger (Hardware)</a></h2>