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]
>>
>>
>>
>>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
