On Tue, May 01, 2007 at 09:12:50AM -0400, Dave Anderson wrote: > 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? > I was referring to Rachita's implementation of doing backtraces using .eh_frame section info. > 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.... Thanks Vivek -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
