Hi Jack, Everyone,

I spent some time looking at the btp stack trace for the case
where the process was blocked (on x86_64 kdb).

With the code in the current 2.6.13 version of the patch the
bta command is likely to fail the stack trace back for most
of the processes.

The problem is that the x86_64 context switch doesn't save 
the rip value.  It does save the rbp and flags on the stack
and then save the rsp value in p->thread.rsp.

The current code calls get_wchan() which looks for a possible
PC value which is not in_sched_functions().  The problem with
this is that we need a matching rsp, rbp and rip.  The get_wchan()
finds an rip but it isn't the one that matches our saved rsp & rbp.

The patch uses "thread_return-1" as the rip.  This will cause
the stack trace back code to find that the process in in schedule().
The patch also adjusts the rsp to undo the two push instructions
in the switch_to macro's inline assembly.  This results in a
matching set of rsp, rbp and rip.

I just did a bta command and all of the processes gave believable
stacks.


Jim Houston - Concurrent Computer Corp.


--- arch/x86_64/kdb/kdba_bt.c.0 2005-08-31 14:19:00.000000000 -0400
+++ arch/x86_64/kdb/kdba_bt.c   2005-08-31 17:33:38.000000000 -0400
@@ -128,6 +128,8 @@
  *     traceback.
  */
 
+extern void thread_return(void);
+
 static int
 kdba_bt_stack(kdb_machreg_t addr, int argcount, struct task_struct *p)
 {
@@ -174,6 +176,7 @@
                         * points to the rbp value, assume kernel space.
                         */
                        rsp = p->thread.rsp;
+#if 0
                        rbp = *(unsigned long *)rsp;
                        cs  = __KERNEL_CS;
                        rip = (kdb_machreg_t)get_wchan(p);
@@ -182,6 +185,22 @@
                                    backtrace not available\n");
                                return(0);
                        }
+#endif
+                       /*
+                        * The rip is no longer in the thread struct.
+                        * We know that the stack value was saved in
+                        * schedule near the label thread_return.
+                        * Setting rip to thread_return-1 lets the
+                        * stack trace find that we are in schedule
+                        * and correctly decode its prologue.  We
+                        * extract the saved rbp and adjust the stack
+                        * to undo the effects of the inline assembly
+                        * code which switches the stack.
+                        */
+                       rbp = *(unsigned long *)rsp;
+                       rip = (kdb_machreg_t)&thread_return-1;
+                       rsp = rsp + 16;
+                       cs  = __KERNEL_CS;
                }
        }
        ss = rsp & -THREAD_SIZE;




---------------------------
Use http://oss.sgi.com/ecartis to modify your settings or to unsubscribe.

Reply via email to