X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=doc%2Fdebug.texi;h=0d5a79deaf6917be4c46e750a1993ef778b29170;hb=0951a7af1bd8e78b5991edd7de9d0370b2d2d72b;hp=8a52be5efaceccd98cc16e4d95f4d0400ac9c615;hpb=f415a37905c57f61b444806bf84f5405184452aa;p=pintos-anon

diff --git a/doc/debug.texi b/doc/debug.texi
index 8a52be5..0d5a79d 100644
--- a/doc/debug.texi
+++ b/doc/debug.texi
@@ -115,10 +115,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
@@ -159,15 +159,15 @@ backtrace kernel.o 0xc0106eff 0xc01102fb 0xc010dc22 0xc010cf67
 The backtrace output would then look something like this:
 
 @example
-0xc0106eff: debug_panic (../../lib/debug.c:86)
-0xc01102fb: file_seek (../../filesys/file.c:405)
-0xc010dc22: seek (../../userprog/syscall.c:744)
-0xc010cf67: syscall_handler (../../userprog/syscall.c:444)
-0xc0102319: intr_handler (../../threads/interrupt.c:334)
-0xc010325a: ?? (threads/intr-stubs.S:1554)
-0x804812c: ?? (??:0)
-0x8048a96: ?? (??:0)
-0x8048ac8: ?? (??:0)
+0xc0106eff: debug_panic (lib/debug.c:86)
+0xc01102fb: file_seek (filesys/file.c:405)
+0xc010dc22: seek (userprog/syscall.c:744)
+0xc010cf67: syscall_handler (userprog/syscall.c:444)
+0xc0102319: intr_handler (threads/interrupt.c:334)
+0xc010325a: intr_entry (threads/intr-stubs.S:38)
+0x0804812c: (unknown)
+0x08048a96: (unknown)
+0x08048ac8: (unknown)
 @end example
 
 (You will probably not see exactly the same addresses if you run the
@@ -209,22 +209,48 @@ panicked, you can re-run @command{backtrace} on the user program, like
 so: (typing the command on a single line, of course):
 
 @example
-backtrace grow-too-big 0xc0106eff 0xc01102fb 0xc010dc22 0xc010cf67
-0xc0102319 0xc010325a 0x804812c 0x8048a96 0x8048ac8
+backtrace tests/filesys/extended/grow-too-big 0xc0106eff 0xc01102fb
+0xc010dc22 0xc010cf67 0xc0102319 0xc010325a 0x804812c 0x8048a96
+0x8048ac8
 @end example
 
 The results look like this:
 
 @example
-0xc0106eff: ?? (??:0)
-0xc01102fb: ?? (??:0)
-0xc010dc22: ?? (??:0)
-0xc010cf67: ?? (??:0)
-0xc0102319: ?? (??:0)
-0xc010325a: ?? (??:0)
-0x804812c: test_main (../../tests/filesys/extended/grow-too-big.c:20)
-0x8048a96: main (../../tests/main.c:10)
-0x8048ac8: _start (../../lib/user/entry.c:9)
+0xc0106eff: (unknown)
+0xc01102fb: (unknown)
+0xc010dc22: (unknown)
+0xc010cf67: (unknown)
+0xc0102319: (unknown)
+0xc010325a: (unknown)
+0x0804812c: test_main (...xtended/grow-too-big.c:20)
+0x08048a96: main (tests/main.c:10)
+0x08048ac8: _start (lib/user/entry.c:9)
+@end example
+
+You can even specify both the kernel and the user program names on
+the command line, like so:
+
+@example
+backtrace kernel.o tests/filesys/extended/grow-too-big 0xc0106eff
+0xc01102fb 0xc010dc22 0xc010cf67 0xc0102319 0xc010325a 0x804812c
+0x8048a96 0x8048ac8
+@end example
+
+The result is a combined backtrace:
+
+@example
+In kernel.o:
+0xc0106eff: debug_panic (lib/debug.c:86)
+0xc01102fb: file_seek (filesys/file.c:405)
+0xc010dc22: seek (userprog/syscall.c:744)
+0xc010cf67: syscall_handler (userprog/syscall.c:444)
+0xc0102319: intr_handler (threads/interrupt.c:334)
+0xc010325a: intr_entry (threads/intr-stubs.S:38)
+In tests/filesys/extended/grow-too-big:
+0x0804812c: test_main (...xtended/grow-too-big.c:20)
+0x08048a96: main (tests/main.c:10)
+0x08048ac8: _start (lib/user/entry.c:9)
 @end example
 
 Here's an extra tip for anyone who read this far: @command{backtrace}
@@ -334,6 +360,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
@@ -354,6 +382,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
@@ -414,6 +444,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