added documentation for thread_foreach functions
[pintos-anon] / doc / debug.texi
index e671b7495b2cc9a6e403abe6b252e1fa0ab24d35..402ede606345d07785666614a18748f6c3c114eb 100644 (file)
@@ -21,13 +21,12 @@ introduces you to a few of them.
 Don't underestimate the value of @func{printf}.  The way
 @func{printf} is implemented in Pintos, you can call it from
 practically anywhere in the kernel, whether it's in a kernel thread or
-an interrupt handler, almost regardless of what locks are held (but see
-@ref{printf Reboots} for a counterexample).
+an interrupt handler, almost regardless of what locks are held.
 
 @func{printf} is useful for more than just examining data.
 It can also help figure out when and where something goes wrong, even
 when the kernel crashes or panics without a useful error message.  The
-strategy is to sprinkle calls to @func{print} with different strings
+strategy is to sprinkle calls to @func{printf} with different strings
 (e.g.@: @code{"<1>"}, @code{"<2>"}, @dots{}) throughout the pieces of
 code you suspect are failing.  If you don't even see @code{<1>} printed,
 then something bad happened before that point, if you see @code{<1>}
@@ -100,6 +99,8 @@ of how your program got where it is, as a list of addresses inside the
 functions that were running at the time of the panic.  You can also
 insert a call to @func{debug_backtrace}, prototyped in
 @file{<debug.h>}, to print a backtrace at any point in your code.
+@func{debug_backtrace_all}, also declared in @file{<debug.h>}, 
+prints backtraces of all threads.
 
 The addresses in a backtrace are listed as raw hexadecimal numbers,
 which are difficult to interpret.  We provide a tool called
@@ -115,10 +116,10 @@ sense (e.g.@: function A is listed above function B, but B doesn't
 call A), then it's a good sign that you're corrupting a kernel
 thread's stack, because the backtrace is extracted from the stack.
 Alternatively, it could be that the @file{kernel.o} you passed to
-@command{backtrace} does not correspond to the kernel that produced
+@command{backtrace} is not the same kernel that produced
 the backtrace.
 
-Sometimes backtraces can be confusing without implying corruption.
+Sometimes backtraces can be confusing without any corruption.
 Compiler optimizations can cause surprising behavior.  When a function
 has called another function as its final action (a @dfn{tail call}), the
 calling function may not appear in a backtrace at all.  Similarly, when
@@ -360,6 +361,8 @@ that links the elements.
 Example: @code{dumplist all_list thread all_elem} prints all elements of
 @struct{thread} that are linked in @code{struct list all_list} using the
 @code{struct list_elem all_elem} which is part of @struct{thread}.
+(This assumes that you have added @code{all_list} and @code{all_elem}
+yourself.)
 @end deffn
 
 @deffn {GDB Macro} btthread thread
@@ -380,6 +383,8 @@ Example: @code{btthreadlist all_list all_elem} shows the backtraces of
 all threads contained in @code{struct list all_list}, linked together by
 @code{all_elem}.  This command is useful to determine where your threads
 are stuck when a deadlock occurs.  Please see the example scenario below.
+(This assumes that you have added @code{all_list} and @code{all_elem}
+yourself.)
 @end deffn
 
 @deffn {GDB Macro} btpagefault
@@ -440,6 +445,10 @@ in your kernel, because your kernel should never crash.  Starting with
 Project 3, the situation will change if you use @func{get_user} and
 @func{put_user} strategy to verify user memory accesses
 (@pxref{Accessing User Memory}).
+
+If you don't want GDB to stop for page faults, then issue the command
+@code{handle SIGSEGV nostop}.  GDB will still print a message for
+every page fault, but it will not come back to a command prompt.
 @end deffn
 
 @node Example GDB Session
@@ -717,14 +726,15 @@ In a case like this, you might appreciate being able to make Bochs
 print out more debug information, such as the exact type of fault that
 occurred.  It's not very hard.  You start by retrieving the source
 code for Bochs 2.2.6 from @uref{http://bochs.sourceforge.net} and
-extracting it into a directory.  Then read
-@file{pintos/src/misc/bochs-2.2.6.README} and apply the patches needed.
-Then run @file{./configure}, supplying the options you want (some
-suggestions are in the patch file).  Finally, run @command{make}.
-This will compile Bochs and eventually produce a new binary
-@file{bochs}.  To use your @file{bochs} binary with @command{pintos},
+saving the file @file{bochs-2.2.6.tar.gz} into a directory.  
+The script @file{pintos/src/misc/bochs-2.2.6-build.sh}
+applies a number of patches contained in @file{pintos/src/misc}
+to the Bochs tree, then builds Bochs and installs it in a directory
+of your choice.
+Run this script without arguments to learn usage instructions.
+To use your @file{bochs} binary with @command{pintos},
 put it in your @env{PATH}, and make sure that it is earlier than
-@file{/usr/class/cs140/`uname -m`/bochs}.
+@file{@value{localpintosbindir}/bochs}.
 
 Of course, to get any good out of this you'll have to actually modify
 Bochs.  Instructions for doing this are firmly out of the scope of