From owner-freebsd-hackers Fri Jan 12 6:55:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp.nettoll.com (matrix.nettoll.net [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 5BAE037B400 for ; Fri, 12 Jan 2001 06:54:57 -0800 (PST) Received: by smtp.nettoll.com; Fri, 12 Jan 2001 15:51:21 +0100 (MET) Message-ID: <3A5F1ACF.6020909@enition.com> Date: Fri, 12 Jan 2001 15:55:11 +0100 From: Xavier Galleri User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: Need help for kernel crash dump analysis References: Content-Type: multipart/alternative; boundary="------------000202050404040402080905" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --------------000202050404040402080905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thank you for your answer, 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: > > 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] > > > > --------------000202050404040402080905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thank you for your answer,

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:


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]

--------------000202050404040402080905-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message