X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?p=pintos-anon;a=blobdiff_plain;f=doc%2Fdebug.texi;h=94926131190c3865fcdd9f58adf0804dfc00dc20;hp=62d951add313c9a3f8ba48c304ff5b773594561f;hb=941eff93628d8fca26ac6359b4cc8326b817beed;hpb=4a7d35125ae6c0b5f244ae556af188de9a49765e diff --git a/doc/debug.texi b/doc/debug.texi index 62d951a..9492613 100644 --- a/doc/debug.texi +++ b/doc/debug.texi @@ -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{}, to print a backtrace at any point in your code. +@func{debug_backtrace_all}, also declared in @file{}, +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 @@ -292,7 +293,6 @@ can pause the process at any point with @key{Ctrl+C}. @menu * Using GDB:: * Example GDB Session:: -* Debugging User Programs:: * GDB FAQ:: @end menu @@ -357,9 +357,9 @@ that contains elements of the given @var{type} (without the word @code{struct}) in which @var{element} is the @struct{list_elem} member that links the elements. -Example: @code{dumplist all_list thread all_elem} prints all elements of +Example: @code{dumplist all_list thread allelem} 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}. +@code{struct list_elem allelem} which is part of @struct{thread}. @end deffn @deffn {GDB Macro} btthread thread @@ -376,16 +376,24 @@ which the threads are kept. Specify @var{element} as the @struct{list_elem} field used inside @struct{thread} to link the threads together. -Example: @code{btthreadlist all_list all_elem} shows the backtraces of +Example: @code{btthreadlist all_list allelem} 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 +@code{allelem}. This command is useful to determine where your threads are stuck when a deadlock occurs. Please see the example scenario below. @end deffn +@deffn {GDB Macro} btthreadall +Short-hand for @code{btthreadlist all_list allelem}. +@end deffn + @deffn {GDB Macro} btpagefault Print a backtrace of the current thread after a page fault exception. Normally, when a page fault exception occurs, GDB will stop -with a message that might say: +with a message that might say:@footnote{To be precise, GDB will stop +only when running under Bochs. When running under QEMU, you must +set a breakpoint in the @code{page_fault} function to stop execution +when a page fault occurs. In that case, the @code{btpagefault} macro is +unnecessary.} @example Program received signal 0, Signal 0. @@ -396,8 +404,8 @@ In that case, the @code{bt} command might not give a useful backtrace. Use @code{btpagefault} instead. You may also use @code{btpagefault} for page faults that occur in a user -process. In this case, you may also wish to load the user program's -symbol table (@pxref{Debugging User Programs}). +process. In this case, you may wish to also load the user program's +symbol table using the @code{loadusersymbols} macro, as described above. @end deffn @deffn {GDB Macro} hook-stop @@ -437,9 +445,16 @@ followed by the output of the @code{btpagefault} command. Before Project 3, a page fault exception in kernel code is always a bug in your kernel, because your kernel should never crash. Starting with -Project 3, the situation will change if you use @func{get_user} and +Project 3, the situation will change if you use the @func{get_user} and @func{put_user} strategy to verify user memory accesses (@pxref{Accessing User Memory}). + +@c ---- +@c Unfortunately, this does not work with Bochs's gdb stub. +@c ---- +@c If you don't want GDB to stop for page faults, then issue the command +@c @code{handle SIGSEGV nostop}. GDB will still print a message for +@c every page fault, but it will not come back to a command prompt. @end deffn @node Example GDB Session @@ -552,12 +567,12 @@ thread. If I run @code{backtrace}, it shows this backtrace: Not terribly useful. What I really like to know is what's up with the other thread (or threads). Since I keep all threads in a linked list called @code{all_list}, linked together by a @struct{list_elem} member -named @code{all_elem}, I can use the @code{btthreadlist} macro from the +named @code{allelem}, I can use the @code{btthreadlist} macro from the macro library I wrote. @code{btthreadlist} iterates through the list of threads and prints the backtrace for each thread: @smallexample -(gdb) @strong{btthreadlist all_list all_elem} +(gdb) @strong{btthreadlist all_list allelem} pintos-debug: dumping backtrace of thread 'main' @@0xc002f000 #0 0xc0101820 in schedule () at ../../threads/thread.c:722 #1 0xc0100f8f in thread_block () at ../../threads/thread.c:324 @@ -588,26 +603,39 @@ is stuck in @func{timer_sleep}, called from @code{test_mlfqs_load_1}. Knowing where threads are stuck can be tremendously useful, for instance when diagnosing deadlocks or unexplained hangs. -@node Debugging User Programs -@subsection Debugging User Programs +@deffn {GDB Macro} loadusersymbols -You can also use GDB to debug a user program running under -Pintos. Start by issuing this GDB command to load the -program's symbol table: +You can also use GDB to debug a user program running under Pintos. +To do that, use the @code{loadusersymbols} macro to load the program's +symbol table: @example -add-symbol-file @var{program} +loadusersymbols @var{program} @end example @noindent 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 +file system, not in the Pintos file system). For example, you may issue: +@smallexample +(gdb) @strong{loadusersymbols tests/userprog/exec-multiple} +add symbol table from file "tests/userprog/exec-multiple" at + .text_addr = 0x80480a0 +(gdb) +@end smallexample + +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 +so be careful in interpreting the results: GDB does not know +which process is currently active (because that is an abstraction +the Pintos kernel creates). 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 GDB command line, instead of @file{kernel.o}, and then using -@code{add-symbol-file} to load @file{kernel.o}.) +@code{loadusersymbols} to load @file{kernel.o}.) +@code{loadusersymbols} is implemented via GDB's @code{add-symbol-file} +command. + +@end deffn @node GDB FAQ @subsection FAQ @@ -717,14 +745,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