Re: Analyzing a 4.0/amd64 panic

[David Laight <david%l8s.co.uk@localhost>]

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