It's difficult to believe that nothing more intuitive and immediate can be done to get the kernel stack of any process from a GDB session on a kernel crash dump. Does it mean that this is something that nobody ever need until now ?
Also, is there a mean to ask GDB to dump the kernel stack of the 'curproc' that has been interrupted at the time of kernel panic ?
Regards,
Xavier
diman wrote:
[EMAIL PROTECTED]">
On Fri, 12 Jan 2001, Xavier Galleri wrote:OK, let's make it a bit clearer !....
[skiped]Now, if you've read my first mail, I was actually asking for help onhow
to dump the stack of an interrupted process with GDB when the
kernelcrash occurs in the context of an isr. Actually, I would like to
know how I could dump the stack of *any* process at the time of the
crash. This way, I would be able to see where my user-land daemon was
lying in the kernel when the interrupt occurs.
To dump stack of *any* (all) process you may write a little kld
wich will:
1) go through a process list,
2) get tf_eip, tf_esp, tf_ebp of a process
3) get p->p_vmspace
4) read process stack frames and all you need by manually
written routine based on procfs_rwmem and old good 'pread'
(which dosn't work now)
Another way is to go through proc list and coredump all the
processes for future manual analisys.
I like such way.
Can anybody point me to some difficults wich can appear while
implementing this?[skiped]
