[Crash-utility] Re: [PATCH 0/3] Display local variables & function parameters from stack frames

Bernhard Walle bernhard.walle at gmx.de
Tue May 26 16:10:08 UTC 2009


Dave Anderson schrieb:
> 
>  - These days you'd be hard-pressed to find a distribution kernel that is
>    compiled with CONFIG_FRAME_POINTER.  And if it is, the handling can
>    be folded into the currently-existing backtracer.  (In fact, the original
>    x86 backtrace code does have a separate code path for kernels that
>    were built without -fomit-frame-pointer.)  But by the time x86_64 came
>    around, -fomit-frame-pointer was pretty much the default, and I don't think
>    I've ever seen an x86_64 dumpfile with frame-pointers, certainly not
>    from a distributor.  So, yes it's nice you've got something that works
>    with that configuration, but it's pretty unrealistic.

AFAIK the hand-written x86_64 assembler code doesn't take the frame
pointer into account. So yes, CONFIG_FRAME_POINTER for x86_64 is really
unrealistic. That may have changed after the x86/x86_64 merge since I
got that statement from Andi Kleen before the merge, but anyway.

>    the starting point.  With the huge cumbersome memory sizes of modern machines,
>    it's more likely that the ELF vmcore seen by the secondary kdump kernel will
>    be run through "makedumpfile -c ..." into the compressed kdump format
>    prior to the dump ever being seen by whoever analyzes it.  At Red Hat, the
>    support organization pretty much makes all customers use "makedumpfile -c ..."
>    by default.  And of course with the compressed kdump format, there is no
>    register set as your starting point.

That's also the default for SLES 11. (At least if they didn't change it
in the meanwhile.)



Regards,
Bernhard




More information about the Crash-utility mailing list