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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
