How to debug user programs with gdb.

[pintos-anon] / doc / debug.texi

diff --git a/doc/debug.texi b/doc/debug.texi
index 961888f297be48973b9af5d56ff28af3fcef23f1..389080d39f0cf2e36be46ec5ad4b907c6502ceed 100644 (file)
--- a/doc/debug.texi
+++ b/doc/debug.texi
@@ -7,7 +7,6 @@ introduces you to a few of them.
 @menu
 * printf::                      
 * ASSERT::                      
-* DEBUG::                       
 * UNUSED NO_RETURN NO_INLINE PRINTF_FORMAT::  
 * Backtraces::                  
 * i386-elf-gdb::                
@@ -53,31 +52,6 @@ When an assertion proves untrue, the kernel panics.  The panic message
 should help you to find the problem.  See the description of
 backtraces below for more information.
 
-@node DEBUG
-@section @code{DEBUG}
-
-The @code{DEBUG} macro, also defined in @file{<debug.h>}, is a sort of
-conditional @func{printf}.  It takes as its arguments the name of a
-``message class'' and a @func{printf}-like format string and
-arguments.  The message class is used to filter the messages that are
-actually displayed.  You select the messages to display on the Pintos
-command line using the @option{-d} option.  This allows you to easily
-turn different types of messages on and off while you debug, without
-the need to recompile.
-
-For example, suppose you want to output thread debugging messages.  To
-use a class named @code{thread}, you could invoke @code{DEBUG} like
-this:
-@example
-DEBUG(thread, "thread id: %d\n", id);
-@end example
-@noindent
-and then to start Pintos with @code{thread} messages enable you'd use
-a command line like this:
-@example
-pintos run -d thread
-@end example
-
 @node UNUSED NO_RETURN NO_INLINE PRINTF_FORMAT
 @section UNUSED, NO_RETURN, NO_INLINE, and PRINTF_FORMAT
 
@@ -318,6 +292,22 @@ that there is a bug in the original Pintos code.  The first and second
 are quite likely, and you should seriously consider both.  We hope
 that the third is less likely, but it is also possible.
 
+You can also use @command{gdb} to debug a user program running under
+Pintos.  Start by issuing this @command{gdb} command to load the
+program's symbol table:
+@example
+add-symbol-file @var{program}
+@end example
+where @var{program} is the name of the program's executable (in the host
+file system, not in the Pintos file system).  After this, you should be
+able to debug the user program the same way you would the kernel, by
+placing breakpoints, inspecting data, etc.  Your actions apply to every
+user program running in Pintos, not just to the one you want to debug,
+so be careful in interpreting the results.  Also, a name that appears in
+both the kernel and the user program will actually refer to the kernel
+name.  (The latter problem can be avoided by giving the user executable
+name on the @command{gdb} command line, instead of @file{kernel.o}.)
+
 @node Debugging by Infinite Loop
 @section Debugging by Infinite Loop