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). Is this
> the PC?
I assume you meant task_struct->reg29) 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
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.
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.