[RFC] [Crash-utility] Patch to use gdb's bt in crash

Thu Aug 24 11:12:59 UTC 2006

Hi Dave

I was trying to implement better backtrace mechanism for crash using 
dwarf info. And was trying to use the embedded gdb itself as gdb 
already uses dwarf information for unwinding stack. I could get 
"gdb bt" command working in "crash" after making one minor bug
fix in gdb_interface.c (Patch appended). Now one can get cleaner 
backtrace particularly in x86_64 case using "gdb bt" command.


crash> bt
PID: 4146   TASK: ffff81022e848af0  CPU: 0   COMMAND: "insmod"
 #0 [ffff81021efadbf8] crash_kexec at ffffffff801521d1
 #1 [ffff81021efadc40] machine_kexec at ffffffff8011a739
 #2 [ffff81021efadc80] crash_kexec at ffffffff801521ed
 #3 [ffff81021efadd08] crash_kexec at ffffffff801521d1
 #4 [ffff81021efadd30] bust_spinlocks at ffffffff8011fd6d
 #5 [ffff81021efadd40] panic at ffffffff80131422
 #6 [ffff81021efadda0] cond_resched at ffffffff804176c3
 #7 [ffff81021efaddb0] wait_for_completion at ffffffff80417701
 #8 [ffff81021efade00] __down_read at ffffffff80418d07
 #9 [ffff81021efade30] fun2 at ffffffff80107017
#10 [ffff81021efade40] fun1 at ffffffff801311b6
#11 [ffff81021efade50] init_module at ffffffff8800200f
#12 [ffff81021efade60] sys_init_module at ffffffff8014c664
#13 [ffff81021efadf00] init_module at ffffffff88002068
#14 [ffff81021efadf80] system_call at ffffffff801096da
    RIP: 00002b2153382d4a  RSP: 00007fff57900a28  RFLAGS: 00010246
    RAX: 00000000000000af  RBX: ffffffff801096da  RCX: 0000000000000000
    RDX: 0000000000512010  RSI: 0000000000016d26  RDI: 00002b21531e5010
    RBP: 00007fff57900c58   R8: 00002b21534f46d0   R9: 00002b21531fbd36
    R10: 0000000000516040  R11: 0000000000000206  R12: 0000000000512010
    R13: 00007fff579015c5  R14: 0000000000000000  R15: 00002b21531e5010
    ORIG_RAX: 00000000000000af  CS: 0033  SS: 002b
crash> gdb bt 15
[Switching to thread 1 (process 4146)]#0  0xffffffff801521d1 in crash_kexec (regs=0x0) at kexec.h:64
64      in kexec.h
#0  0xffffffff801521d1 in crash_kexec (regs=0x0) at kexec.h:64
#1  0xffffffff80131422 in panic (fmt=0xffffffff8044832c "Rachita triggering panic\n") at kernel/panic.c:87
#2  0xffffffff80107017 in fun2 (i=0) at init/main.c:608
#3  0xffffffff801311b6 in fun1 (j=Variable "j" is not available.
) at kernel/panic.c:278
#4  0xffffffff8800200f in ?? ()
#5  0xffffc2000023d9d0 in ?? ()
#6  0xffffffff8014c664 in sys_init_module (umod=0xffff81022ef6c400, len=18446604445110683424,
    uargs=0xffff81022ef6c6e8 "\020304366.\002\201377377x304366.\002\201377377340304366.\002\201377377H305366.\002\201377377260305366.\002\201377377\030306366.\002\201377377\200306366.\002\201377377")
    at kernel/module.c:1911
#7  0xffffffff801096da in system_call () at bitops.h:230
#8  0x00002b2153382d4a in ?? ()
#9  0xffff81022e8516d0 in ?? ()
#10 0xffffffff8055c7c0 in migration_notifier ()
#11 0x0000000000000000 in ?? ()
#12 0x0000000000000001 in ?? ()
#13 0xffffffffffffffff in ?? ()
#14 0xffffffff8013ae2a in recalc_sigpending () at kernel/signal.c:227
(More stack frames follow...)
crash>

===============================================================================


But as of now there are few issues with "gdb bt"

1) Sometimes the no. of stack frames displayed doesn't end for a long time
   and also the "q" command doesn't work as desired once the screen is full.
   The workaround is to give some limiting count like "gdb bt 10". 
   I tried gdb ver 6.1 externally (outside crash) also and see the same
   long ending stack frames where as the latest gdb (ver 6.4), works fine. So
   just wondering if you are planning to upgrade embedded gdb to ver 6.4?

2) As unlike crash, there is no concept of tasks in gdb, we can only see the
   backtraces for tasks active at the time of crash.

 
Apart from "bt" this change also allows to get some other related commands
like "gdb info registers", "gdb info frame" and "gdb info threads" working.


Please let me know your comments about the approach.

Thanks
Rachita



  o This patch fixes the broken crash-gdb interface for running gdb commands
    in crash. Earlier the "argc" was not right and the commands to gdb used to
    fail. The patch increments the argc correctly.

  o This will particularly help in using the gdb backtrace mechanism for
    active tasks at the point of crash. We now implicitly change the "thread" 
    id for gdb to the current context cpu before issuing the "bt" command to
    embedded gdb.

Signed-off-by: Rachita Kothiyal <rachita at in.ibm.com>
---

 gdb_interface.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff -puN gdb_interface.c~crash_use_gdb_bt gdb_interface.c

--- crash-4.0-3.1/gdb_interface.c~crash_use_gdb_bt	2006-08-24 15:21:22.527601072 +0530
+++ crash-4.0-3.1-rachita/gdb_interface.c	2006-08-24 15:51:51.314583192 +0530
@@ -58,6 +58,7 @@ gdb_main_loop(int argc, char **argv)
 
         optind = 0;
         command_loop_hook = main_loop;
+	argc ++;
 
 #if defined(GDB_5_3) || defined(GDB_6_0) || defined(GDB_6_1)
         gdb_main_entry(argc, argv);
@@ -670,6 +671,7 @@ void
 cmd_gdb(void)
 {
         int c;
+	char *thread_cmd;
 
         while ((c = getopt(argcnt, args, "")) != EOF) {
                 switch(c)
@@ -703,6 +705,18 @@ cmd_gdb(void)
 	            whitespace(pc->orig_line[3]))
 			shift_string_left(pc->orig_line, strlen("gdb")+1); 
 	
+		/*
+		 * If the request is a backtrace then switch context to
+		 *  current context in gdb too
+ 		 */
+		if ((strncmp(clean_line(pc->orig_line), "backtrace", 9) == 0) ||
+		    (strncmp(clean_line(pc->orig_line), "bt", 2) == 0)) {
+			thread_cmd = GETBUF(BUFSIZE);
+			sprintf(thread_cmd, "thread %d",
+				CURRENT_CONTEXT()->processor + 1);
+			gdb_pass_through(thread_cmd, NULL, 0);
+			FREEBUF(thread_cmd);
+		}
 		gdb_pass_through(clean_line(pc->orig_line), NULL, 0);
 	}
 }
@@ -836,5 +850,3 @@ get_frame_offset(ulong pc)
 	    "get_frame_offset: invalid request for non-alpha systems!\n"));
 }
 #endif /* !ALPHA */ 
-
-
_


