Hi everybody,
I have made some progress on my kernel crash dump issue and here is a
little contribution for those who would encounter the same problem as
the one I got to deal with kernel stack dump.
To begin, I recall the actual issue which is : how could I get the stack
dump of the current process when a crash occurs inside an interrupt
handler ?
The clue lies in the use of the 'curpcb' information (current process
control block, or alike). Traditionally, this is where at least part of
the current process-specific kernel information are stored (such as
kernel stack base adress, user values of CPU register set, ...). The
problem I encountered is that, in the context of an interrupt handler,
both DDB (during on-line crash debugging) and GDB (during post-mortem
crash dump analysis) give me for 'curpcb' the one at the time of crash,
which is (surely) that of the kernel (I deduced this from that 'curproc'
is 0). Anyway, this is not the one I need, and I still wonder how this
could be get with no special trick !
Thus, since my problem is rather deterministic, I decided to 'printf'
the 'curpcb' (and 'curproc') short before the panic condition occurs.
And then I could apply the following manual technic to get the stack
dump (let's say your 'curcpb' value is 0xCURPCB).
(kgdb) p /x ((struct pcb*)0XCURPCB)->pcb_ebp
$0 = 0xCUREBP
(kgdb) p /x ((struct pcb*)0XCURPCB)->pcb_eip
$1 = 0xCUREIP
(kgdb) frame 0xCUREBP 0xCUREIP
#0 ... /* This normally tells you where you were at the time the next
function has been called */ ...
(kgdb) info frame 0xCUREBP 0xCUREIP
Stack frame at 0xCUREBP:
eip = 0XCUREIP in 'function' (path/source.c:line); saved eip 0xPREVEIP
called by frame at 0XPREVEBP
...
Then, you apply the 'frame' command using 0xPREVEBP and 0XPREVEIP and
this way recursively as long as you need (or can ;-).
To sum up, the 'frame' command is used to display one frame level
execution state and the 'info frame' is used to know from where the
frame has been created so that we could get the previous 'frame' data !
Hope this helps,
Xavier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
