[Lldb-commits] [PATCH] D63667: Support __kernel_rt_sigreturn in frame initialization

Fri Jun 21 13:55:38 PDT 2019

JosephTremoulet added a comment.

FYI, I sent mail about this to lldb-dev.. I'll copy the contents here for the benefit of anybody who didn't see it there but could use the context:

> Hi,
> 
> I'm trying to use lldb in a project where I need to report stack traces from signal handlers, and need to do so on aarch64 Linux.  Even for "synchronous" signal handling, I'm hitting a couple issues preventing this from working "out of the box":
>  1 - The platform signal handler trampoline function on the stack is `__kernel_rt_sigreturn`, not `sigtramp`.  I'm wondering if it's ok to just add `__kernel_rt_sigreturn` to the list of trap handler symbol names in PlatformLinux, or if I need to include it in "UserSpecifiedTrapHandlerFunctionNames", or something else
>  2 - When the user handler is invoked, its return address is set to the very first byte of `__kernel_rt_sigreturn`, which throws off unwinding because we assume that frame must really be at a call in the preceding function.  I asked about this on IRC, where Jan Kratochvil mentioned that the decrement shouldn't happen for frames with S in the eh_frame's augmentation.  I've verified that `__kernel_rt_sigreturn` indeed has the S.  I'm not sure where I'd find official documentation about that, but the DWARF Standards Committee's wiki[1] does link to Ian Lance Taylor's blog[2] which says "The character ‘S’ in the augmentation string means that this CIE represents a stack frame for the invocation of a signal handler. When unwinding the stack, signal stack frames are handled slightly differently: the instruction pointer is assumed to be before the next instruction to execute rather than after it."  So I'm interested in encoding that knowledge in LLDB, but not sure architecturally whether it would be more appropriate to dig into the eh_frame record earlier, or to just have this be a property of symbols flagged as trap handlers, or something else.
> 
> I'd very much appreciate any feedback on this.  I've put up a patch[3] on Phab with a testcase that demonstrates the issue (on aarch64 linux) and an implementation of the low-churn "communicate this in the trap handler symbol list" approach.
> 
> Thanks,
> -Joseph
> 
> [1] - http://wiki.dwarfstd.org/index.php?title=Exception_Handling
>  [2] - https://www.airs.com/blog/archives/460
>  [3] - https://reviews.llvm.org/D63667

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63667