@menu
* printf::
* ASSERT::
-* DEBUG::
* UNUSED NO_RETURN NO_INLINE PRINTF_FORMAT::
* Backtraces::
* i386-elf-gdb::
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
assertion
@example
-ASSERT (file_ofs >= )0;
+ASSERT (file_ofs >= 0);
@end example
@noindent
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