linux-mips
[Top] [All Lists]

Re: how to get a process backtrace from kernel gdb?

To: Srinivas Kommu <kommu@hotmail.com>
Subject: Re: how to get a process backtrace from kernel gdb?
From: Ralf Baechle <ralf@linux-mips.org>
Date: Wed, 22 Mar 2006 10:50:26 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <4420940B.9030605@hotmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4420940B.9030605@hotmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.4.2.1i
On Tue, Mar 21, 2006 at 04:02:19PM -0800, Srinivas Kommu wrote:

> I'm running gdb on vmlinux connected to a remote target (2.4 kernel). I 
> have the task_struct address of 'current' and other processes. Is it 
> possible to get a symbolic stack trace of the kernel stack? Where is the 
> kernel stack located? I tried to print (task_struct->reg29)[13]. Is this 
> the PC?

I assume you meant task_struct->reg29)[31] which is the address at which
the process is going to resume execution when it's time has arrived.  But
in most cases this address isn't terribly interesting.  So we have two
cases here:

 o $31 pointing to ret_from_fork
   This is a new born process which will begin it's active life of
   execution on a CPU at ret_from_fork.  This is where the resume function
   will jump to which may well be not the scheduler function.
 o Otherwise:
   The thread is regaining the CPU and the resume() call is going to return
   straight to it's caller, kernel/sched.c:context_switch() which inlined
   into schedule() and what we actually want is schedule's caller, so we
   dig through the scheduler's stack frame.  To make things more
   entertaining the stack frame will change with configuration options and
   compiler used, so we basically have to disassemble the stackframe.

   For get_wchan We repeat that exercise in the cases we one of the other
   scheduler functions may have called schedule() until we reach a
   non-schedule function.  So now we have a pointer that actually points to
   something interesting, a driver or other kernel subsystem.

The whole thing is a bit of a mindbender.  Why?  The scheduler is designed
to deliver best possible performance and we've not compromized on
performance to make the job of backtracing any easier.

> PS. I broke into gdb using a hotkey on the serial console; so the gdb 
> backtrace shows the serial driver.

In which you need to be extra careful about the validity of any pointer
you might encounter.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>