Full gdb backtrace

diff --git a/docs/howtos/HowToDebugVKernels/index.mdwn b/docs/howtos/HowToDebugVKernels/index.mdwn
index 8a51dc3..0b3cd41 100644 (file)
--- a/docs/howtos/HowToDebugVKernels/index.mdwn
+++ b/docs/howtos/HowToDebugVKernels/index.mdwn
@@ -79,6 +79,7 @@ sys_ktrace, allproc_scan, etc represent the function names. The hex values in pa
 The last hex value is the instruction address. Since ddb doesn't really know how many arguments a function takes, it always prints five.
 
 # Gdb
+
 Quoting from vkernel(7):
 
 It is possible to directly gdb the virtual kernel's process.  It is recommended that you do a `handle SIGSEGV noprint' to ignore page faults processed by the virtual kernel itself and `handle SIGUSR1 noprint' to ignore signals used for simulating inter-processor interrupts (SMP build only).
@@ -100,19 +101,40 @@ So we are going to attach to the vkernel process:
 Let's get a trace from inside gdb:
 
     (gdb) bt
-    #0  0x282d4c10 in sigsuspend () from /usr/lib/libc.so.6
-    #1  0x28287eb2 in sigsuspend () from /usr/lib/libthread_xu.so.2
-    #2  0x0821530a in stopsig (nada=24, info=0x40407d2c, ctxp=0x40407a4c) at /usr/src/sys/platform/vkernel/i386/exception.c:112
-    #3  <signal handler called>
-    #4  0x282d4690 in umtx_sleep () from /usr/lib/libc.so.6
-    #5  0x08213bde in cpu_idle () at /usr/src/sys/platform/vkernel/i386/cpu_regs.c:722
-    #6  0x00000000 in ?? ()
+    #0  0x282d60d0 in read () from /usr/lib/libc.so.6
+    #1  0x2828389f in read () from /usr/lib/libthread_xu.so.2
+    #2  0x0821cd86 in vconsgetc (private=0x56758168) at /usr/src/sys/platform/vkernel/platform/console.c:373
+    #3  0x080e431d in cngetc () at /usr/src/sys/kern/tty_cons.c:482
+    #4  0x080813d0 in db_readline (lstart=0x82806a0 "", lsize=120) at /usr/src/sys/ddb/db_input.c:314
+    #5  0x08081c43 in db_read_line () at /usr/src/sys/ddb/db_lex.c:55
+    #6  0x080804ff in db_command_loop () at /usr/src/sys/ddb/db_command.c:467
+    #7  0x08082ef8 in db_trap (type=12, code=4) at /usr/src/sys/ddb/db_trap.c:71
+    #8  0x082125aa in kdb_trap (type=12, code=4, regs=0x5746c8cc) at /usr/src/sys/platform/vkernel/i386/db_interface.c:151
+    #9  0x082143e1 in trap_fatal (frame=0x5746c8cc, usermode=<value optimized out>, eva=0)
+        at /usr/src/sys/platform/vkernel/i386/trap.c:1031
+    #10 0x0821453e in trap_pfault (frame=0x5746c8cc, usermode=0, eva=0) at /usr/src/sys/platform/vkernel/i386/trap.c:948
+    #11 0x0821468d in kern_trap (frame=0x5746c8cc) at /usr/src/sys/platform/vkernel/i386/trap.c:709
+    #12 0x0821528c in exc_segfault (signo=11, info=0x5746cb98, ctxp=0x5746c8b8)
+        at /usr/src/sys/platform/vkernel/i386/exception.c:181
+    #13 <signal handler called>
+    #14 0x080aca52 in ktrace_clear_callback (p=0x567480c0, data=0x5746cc5c) at /usr/src/sys/kern/kern_ktrace.c:347
+    #15 0x080b2e91 in allproc_scan (callback=0x80aca14 <ktrace_clear_callback>, data=0x5746cc5c)
+        at /usr/src/sys/kern/kern_proc.c:533
+    #16 0x080acffe in sys_ktrace (uap=0x5746cca0) at /usr/src/sys/kern/kern_ktrace.c:276
+    #17 0x08214b6d in syscall2 (frame=0x5746cd40) at /usr/src/sys/platform/vkernel/i386/trap.c:1273
+    #18 0x08214d9c in user_trap (frame=0x5746cd40) at /usr/src/sys/platform/vkernel/i386/trap.c:413
+    #19 0x082151ac in go_user (frame=0x5746cd38) at /usr/src/sys/platform/vkernel/i386/trap.c:1473
+    #20 0x08215462 in pmsg4 () at /usr/src/sys/platform/vkernel/i386/fork_tramp.s:103
     (gdb) 
 
-Why does it differ from the ddb's trace ?
-Well, when the vkernel is sitting at a db> prompt all vkernel threads representing virtual cpu's except the one handling the db> prompt itself will be suspended in stopsig(). The backtrace only sees one of the N threads.
+At this point we can examine the data of various variables. Keep in mind that bare addresses must be cast to the respective data type, prior to accessing. E.g.:
 
-We need to do better this time. Let's break into the kernel _before_ it crashes. sys_ktrace() seems like a good candidate.
+    (gdb) print ((struct proc *)0x567480c0)->p_pid
+    $6 = 690
+    (gdb) 
+
+
+Let's try this time to break into the kernel _before_ it crashes. sys_ktrace() seems like a good candidate.
 
     # gdb kernel 25532
     GNU gdb 6.7.1
@@ -157,3 +179,18 @@ Let's see if this process is traced:
     (gdb) 
 
 Oops. There is no trace to a vnode for this process. The code will try to access p->p_tracenode and is bound to crash. This is the zero virtual address we saw before.
+
+# Possible errors
+
+    (gdb) bt
+    #0  0x282d4c10 in sigsuspend () from /usr/lib/libc.so.6
+    #1  0x28287eb2 in sigsuspend () from /usr/lib/libthread_xu.so.2
+    #2  0x0821530a in stopsig (nada=24, info=0x40407d2c, ctxp=0x40407a4c) at /usr/src/sys/platform/vkernel/i386/exception.c:112
+    #3  <signal handler called>
+    #4  0x282d4690 in umtx_sleep () from /usr/lib/libc.so.6
+    #5  0x08213bde in cpu_idle () at /usr/src/sys/platform/vkernel/i386/cpu_regs.c:722
+    #6  0x00000000 in ?? ()
+    (gdb) 
+
+Why does it differ from the ddb's trace ?
+Well, when the vkernel is sitting at a db> prompt all vkernel threads representing virtual cpu's except the one handling the db> prompt itself will be suspended in stopsig(). The backtrace only sees one of the N threads.