<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <tt>> There still are a couple of things which need to be done, viz</tt> <tt>> 1. Extend to obtaining unwind info from modules as well(currently</tt> <tt>> doing only for the kernel)</tt> <tt>> 2. Currently reading the unwind info from eh_frame section only(ie</tt> <tt>> __start_unwind to __end_unwind). Need to add facility to read from</tt> <tt>> the .debug_frame(if .debug_frame is present in cases where .eh_frame</tt> <tt>> is absent. Will have to read from the vmlinux if we want to read the</tt> <tt>> .debug_frame info)</tt> <tt>Hi Rachita,</tt><tt></tt> <tt>I hope to be able to come up with a new crash version</tt> <tt>for you to continue working with by tomorrow, Monday at</tt> <tt>the latest.</tt><tt></tt> <tt>Off the top of my head, here's what I've done with your</tt> <tt>initial patch:</tt><tt></tt> <tt>1. As Ben mentioned, it need to be made compilable for</tt> <tt> other architectures.</tt> <tt>2. Renamed unwind_x86_64.c into unwind_x86_32_64.c,</tt> <tt> because the unwind code should be architecture</tt> <tt> neutral with respect to x86 and x86_64. It's currently</tt> <tt> #ifdef'd to only be compile if X86_64, but when a</tt> <tt> new "unwind_x86.h" file is ready to go, it can be</tt> <tt> made usable by both arches.</tt> <tt>3. Made it capable of reading .eh_frame data from the</tt> <tt> vmlinux file if it is not in memory.</tt> <tt>4. Made it capable of reading all of the module's unwind</tt> <tt> tables.</tt> <tt>5. Restored the unwind() function to reflect the kernel</tt> <tt> version in that it new uses a new find_table() routine,</tt> <tt> which returns a pointer to the local copy of the unwind</tt> <tt> that contains the incoming pc.</tt> <tt>6. Cleaned up a bunch of cruft...</tt><tt></tt> <tt>A couple other notes:</tt><tt></tt> <tt>I've restored the original x86_64_low_budget_back_trace_cmd()</tt> <tt>function, and renamed your modified version of it. I can't</tt> <tt>risk breaking the original, and having a new version that</tt> <tt>can be swapped in dynamically to the machdep->back_trace</tt> <tt>pointer will allow us to tinker with the new one. Ideally</tt> <tt>the new one could continue to use the multiple stack walkers</tt> <tt>of the original function, but as they walk through the stacks</tt> <tt>from a "known good" starting point, they could use the new</tt> <tt>unwind functionality to simply calculate the frame size,</tt> <tt>and thereby skip over the leftovers -- as opposed to laboriously</tt> <tt>printing every kernel text return address found -- and as</tt> <tt>opposed to the way you send it off to dwarf_backtrace().</tt> <tt>That being said, your dwarf_backtrace() function is an</tt> <tt>excellent proof-of-concept!</tt><tt></tt> <tt>The same thing goes for the x86 port. In a perfect scenario,</tt> <tt>the back trace code can be left pretty much untouched</tt> <tt>*except* for one key function, that being the get_framesize()</tt> <tt>function in lkcd_x86_trace.c. As the backtrace code is</tt> <tt>walking through the proces and IRQ stacks, it starts with</tt> <tt>the "known good" PC, and calls get_framesize() to determine</tt> <tt>how much of the stack to skip over to find the next text</tt> <tt>return reference. That code has been hacked to hell, and</tt> <tt>as the compiler has gotten more and more clever, it's been</tt> <tt>more and more prone to miscalculating the frame size. It</tt> <tt>disassembles the code from the start of the containing function</tt> <tt>of the passed-in PC up to the PC, counts pushes and pops,</tt> <tt>subtractions of the stack pointer, tries to handle embedded</tt> <tt>returns, etc, etc. -- it's a nightmare. But it seemingly</tt> <tt>could take the passed in PC, and just pass it the unwind</tt> <tt>code to get a "confident" frame size, and go from there.</tt><tt></tt> <tt>That's what I'm hoping for, anyway...</tt><tt></tt> <tt>Anyway, the use of the new unwind info is turned "off" by</tt> <tt>default, but you can turn it on during runtime by entering</tt> <tt>"set unwind on", or turn it off by entering "set unwind off".</tt> <tt>Of course it will not allow you to turn it on if the kernel</tt> <tt>and vmlinux both don't contain any unwind info.</tt><tt></tt> <tt>BTW, I also tried using the .debug_frame section of the vmlinux</tt> <tt>file, but it apparently can not be used by the ported</tt> <tt>kernel unwind code. The kernel unwind code presumes the</tt> <tt>data is from the .eh_frame section; the .debug_frame section</tt> <tt>must use a different layout.</tt><tt></tt> <tt>This is looking good...</tt><tt></tt> <tt>Thanks,</tt> <tt> Dave</tt><tt></tt> <tt> </tt> </html>