[Lldb-commits] [PATCH] D86417: [lldb] do not propagate eTrapHandlerFrame repeatedly

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

If I understand correctly, in

  frame #0: 0x00000000004006bb a.out`handler(sig=6) at main.c:7:5
  frame #1: 0x00007ffff7a555a0 libc.so.6`__restore_rt
  frame #2: 0x00007ffff7a55520 libc.so.6`raise + 272
  frame #3: 0x00007ffff7a56b01 libc.so.6`abort + 337

lldb thinks that both frames 1 & 2 are trap handler frames.  They have full register context available for the frame above them on the stack (that is, frames 2 & 3) and frames 2 & 3 were interrupted asynchronously.  This doesn't sound right?  How do we decide what is a trap handler frame?  One way is to look for the 'S' augmentation in the eh_frame / dwarf debug_frame CIE/FDE for the function -

  unwind_plan.SetUnwindPlanForSignalTrap(
    strchr(cie->augmentation, 'S') ? eLazyBoolYes : eLazyBoolNo);

The other way is from the Platform `CalculateTrapHandlerSymbolNames` method.  PlatformLinux sets these to

  void PlatformLinux::CalculateTrapHandlerSymbolNames() {
    m_trap_handlers.push_back(ConstString("_sigtramp"));
    m_trap_handlers.push_back(ConstString("__kernel_rt_sigreturn"));
    m_trap_handlers.push_back(ConstString("__restore_rt"));

is one of these wrong?

Maybe start with a simpler question -- does `abort` call `raise`?  Like, through a normal CALLQ?  Does `raise` call `__restore_rt`?  Through a normal CALLQ?  Do any of these have the 'S' augmentation string in their eh_frame? `UnwindPlan::Dump` should print whether an unwindplan says it is a trap handler or not, but it doesn't currently (sigh).  If it did, you could do `image show-unwind -n raise` and see what lldb thinks it is.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86417/new/

https://reviews.llvm.org/D86417