[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