----- Original Message ----- > > All, > > 1. Crash version 7.0.8 (debian8) never actually sets DWARF_UNWIND due to > a bug in initialization order: first, `kernel_init` is called that > checks whether the DWARF_UNWIND bit is set and, if not, sets > NO_DWARF_UNWIND. Correct -- DWARF_UNWIND only gets set if the user wants it, so by default it should never be set. The check in kernel_init() exists to handle the case where DWARF_UNWIND was explicitly set by a "set unwind on" command in a .crashrc file. > Then the `init_unwind_table` called that sets DWARF_UNWIND only if > NO_DWARF_UNWIND is not set. So, the resulting `kt->flags` are > (DWARF_UNWIND_EH_FRAME | NO_DWARF_UNWIND) and the > `x86_64_low_budge_back_trace_cmd` is always called despite having the > DWARF tables loaded. Right. x86_64_low_budge_back_trace_cmd() is the default backtrace function. The alternative x86_64_dwarf_back_trace_cmd() backtrace function was added by IBM back in the 4.0-3.8 timeframe in 2006. It has not been maintained much since then (if at all), so I don't even know how well it even works. Personally, I've never utilized it. > 2. When setting DWARF_UNWIND by gdb, the only result that backtrace > shows is the address inside the `__schedule` derived via > `x86_64_thread_return_init`. You can enter "set unwind on" during runtime. > This is due to the two things: > > First, `thread_return` points to the address after `callq __switch_to` > and this address is not on the stack of the original thread since the > stacks were switched already early. Setting `thread_return` to the > address just before stacks are swapped wont help either because of the > below. > > Second, since the Kernel lacks CFI instructions in `context_switch` > macro the stack state before the `rsp` swap is slightly different > comparing to what is described in the debug info, at exactly two longs > because of `pushfq; push %rbp`. Manually adjusting `frame.regs.rsp` at > the entry to the `unwind` fixes this, yielding in a correct DWARF_UNWIND > output from the `bt` command. > > 3. I'm asking for an advice on how to fix that. > > My proposal is to switch `thread_return` to point to the code right > before stacks are swapped since it seems that the current implementation > wrongly assumes that the `thread_return` value will be on the stack of > original thread. This, however, is not required to fix DWARF_UNWIND. > > Next, the stack should be adjusted right before we enter the > `x86_64_dwarf_back_trace_cmd` routine based on what the disassembly of > `context_switch` macro. > > Does this seems correct to you guys? As to advice, you're on your own, unless the original author -- or someone else who actually still uses it -- wants to step up and resurrect support of the functionality. Feel free to file a patch. All I ask is that any changes you make do not affect the default functionality. Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
