Re: [Crash-utility] crash version 4.0-4.1 is available
Vivek Goyal wrote:
> >
> > Hi Dave,
> >
> > Why to go for this approach? Does it give better backtraces as compared
> > to retrieving the information from kernel vmlinux (unwind info) or
> > from debug sections?
> >
>
> Why go for this approach? Because it works?
>
> I don't understand what you mean by "Does it give better backtraces as
> compared to..." What are you talking about -- compared to what?
>
I was referring to Rachita's implementation of doing backtraces using
.eh_frame section info.
Right... and that's what I was referring to below -- which unfortunately never
became an "implementation".
> The initial attempt to use the unwind/debug data was never accomplished,
> and then the rug was pulled when CONFIG_UNWIND_INFO was de-configured
> from the kernel, leaving the kernel being built with
-fno-asynchronous-unwind-tables
> and the vmlinux .eh_frame section discarded.
Hm..., So no .eh_frame now in RHEL kernels. I remember that previously we
had discussed the approach of parsing .debuginfo or similar section generated
by gcc. I am not sure what -fno-asynchronous-unwind-tables does. Does not
generate unwind tables? Does that mean now there is no way of doing backtraces
looking at .dwarf debuginfo? But there has to be one as gdb does it. Hmm....
As has always been the case, if and when you guys figure it out how to
do it, by all means send me a patch for an alternate mechanism that can
cover all configuration bases, doesn't require an ELF format dumpfile,
doesn't abort when it bumps into an exception frame, can switch between
the 3 types of kernel stacks, etc...
Dave