Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Srinivas Kommu <kommu@hotmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: how to get a process backtrace from kernel gdb?
Date: Wed, 22 Mar 2006 10:50:26 +0000	[thread overview]
Message-ID: <20060322105026.GA3129@linux-mips.org> (raw)
In-Reply-To: <4420940B.9030605@hotmail.com>

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

  reply	other threads:[~2006-03-22 10:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-22  0:02 how to get a process backtrace from kernel gdb? Srinivas Kommu
2006-03-22 10:50 ` Ralf Baechle [this message]
2006-03-22 11:11   ` Fuxin Zhang
2006-03-22 11:32     ` Ralf Baechle
2006-03-22 11:40       ` Fuxin Zhang
2006-03-22 12:04         ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060322105026.GA3129@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=kommu@hotmail.com \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox