Re: Analyzing a 4.0/amd64 panic

On Mon, Nov 24, 2008 at 10:46:02PM +0100, Edgar Fu? wrote:
> > The kernel is compiled with frame pointers,
> Oh, that's good news.
Except that it got changed after 4.0 was branched :-(
> However, I can't make sense out of the stack data. Is it possible to let
> gdb automatically traverse the frame pointers?
gdb won't do a backtrace without the 'eh_frame' debug info that would be
part of the loadable executable - so has to be disabled for the kernel
(and anything else that isn't 'demand page loaded' from disk).
> Here are the registers:
> (gdb) info registers
> rax 0x0 0
> rbx 0x10 16
> rcx 0x0 0
> rdx 0x0 0
> rsi 0x0 0
> rdi 0x0 0
> rbp 0xffffffff80380e40 0xffffffff80380e40 <sddump>
> rsp 0xffff80004e2c9818 0xffff80004e2c9818
> r8 0x0 0
> r9 0x0 0
> r10 0x0 0
> r11 0x0 0
> r12 0x1 1
> r13 0xdb627000 3680661504
> r14 0xfbef0000 4226744320
> r15 0xffffffff8036cb5a -2143892646
> rip 0x100 0x100
> eflags 0x0 0
> ds 0x0 0
> es 0x0 0
> fs 0x0 0
> gs 0x0 0
> ...
That isn't the correct interpretation of the saved registers.
In particular eflags cannot be zero - which is a very good hint,
r14 looks more like a possible eflags value.
Unfortunately gdb doen't give you the base address of the trap frame
with the saved registers making it hard to sort them out yourself.
(and it won't have displayed them in what it thinks is the structure order).
What are labelled as rbp and r15 look like code addresses, rsp might be valid.
> and here's the top of the stack (assuming that a amd64 stack works like the
> stacks I used to know):
The stack will look much like an i386 one, expect that the first 6
arguments are passed in registers - so won't appear before the
return address. OTOH they often need saving inside the function
(or some callee saved register must be saved instead) to the stack
used inside the function is larger.
> 0xffff80004e2c9818: 0xffffffff8036cb5a 0x00000000fbef0000
... deleted since it doesn't make much sense without the symbol table
... and disassembled kernel.
>
> > If that printf is actually in the call sequence, then identifying it
> > is probably useful info!
> What do you mean by ,,identifying it''?
Finding where it is called from in the source ...
David
--
David Laight: david%l8s.co.uk@localhost