[Crash-utility] crash version 4.0-4.1 is available

[Dave Anderson]

Vivek Goyal wrote:

> On Fri, Apr 27, 2007 at 12:12:29PM -0400, Dave Anderson wrote:
> >
> > - Implemented dependable backtraces for the x86_64 architecture. (!!!)
> >   This feature builds upon the current "low_budget" backtrace function,
> >   and also required the fix for the BUG()/ud2a disassembly problem
> >   addressed in 4.0-3.22.  It does not require kernel unwind support,
> >   but rather it calculates function framesizes by disassembling the
> >   code from the beginning of the function to the point where it calls
> >   the next function, parsing for add or sub instructions on the rsp,
> >   and for push and pop instructions, thereby determining the framesize
> >   of the function at the point of the call.  This is similar to what is
> >   done for x86, but requires far less hackery.  You will notice a slight
> >   hitch the first time a "bt" is done on a task, but for each text
> >   return address in any backtrace, its framesize is cached for all
> >   subsequent instances.  It also accounts for backtrace text return
> >   addresses from the .text.lock section, by appending "(via function)"
> >   to the end of the frame line.  Also, because it layers on top of the
> >   current backtrace code, it does not compromise the capability of
> >   switching between the process, IRQ, and exception stacks.  That all
> >   being said, 100% accuracy cannot be guaranteed.  But for the ~30
> >   sample dumpfiles I keep around for x86_64 testing, I cannot find any
> >   obviously invalid backtraces.  However, if there is any doubt, the
> >   "bt -o" option will perform backtraces using the "old" manner; and
> >   "bt -O" will force the old manner to always be used.  Of course the
> >   "bt -t" and "bt -T" options are still available.  It's interesting to
> >   redirect the output of "foreach bt" to a file using this version, and
> >   then compare it with the output from an older version.
> >   (anderson at redhat.com)
> >
>
> 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?

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.

Dave