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@xxxxxxxxxx) > > > > 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
