From owner-freebsd-hackers Mon Jan 15 7:33: 7 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 4829937B400 for ; Mon, 15 Jan 2001 07:32:46 -0800 (PST) Received: by smtp.nettoll.com; Mon, 15 Jan 2001 16:28:54 +0100 (MET) Message-ID: <3A63181C.9020108@wanadoo.fr> Date: Mon, 15 Jan 2001 16:32:44 +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: <3A5F1ACF.6020909@enition.com> Content-Type: multipart/alternative; boundary="------------040506060101090909000007" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --------------040506060101090909000007 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, My little problem does not seem to make anybody enthousiastic, at which point that I am wondering if there is any GDB user on kernel dump listening over there ... Maybe I am on the wrong mailing list ? Or should I look for further help somewhere else ? Or is it that my explanations were not clear enough ? I have found that issuing an 'info frame @ebp @eip' command could provide the beginning of a stack dump analysis. Now, I am trying to find out where is stored the stack frame of the current process when an interrupt occurs. Is there anybody who knows this ? Regards Xavier Galleri wrote: > 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] >> >> >> >> > --------------040506060101090909000007 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Hi everybody,

My little problem does not seem to make anybody enthousiastic, at which point that I am wondering if there is any GDB user on kernel dump listening over there ... Maybe I am on the wrong mailing list ? Or should I look for further help somewhere else ? Or is it that my explanations were not clear enough ?

I have found that issuing an 'info frame @ebp @eip' command could provide the beginning of a stack dump analysis. Now, I am trying to find out where is stored the stack frame of the current process when an interrupt occurs. Is there anybody who knows this ?

Regards

Xavier Galleri wrote:

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]

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