Hi Eugene,

the libc signal trampoline should have .eh_frame unwind info (I am
assuming this is x86_64 btw), and last time I looked at it, it seemed
that it should be able to handle sigaltstack(). However, I have never
tested this, so it's quite possible there is still some bug hidden
there. Could you file a bug with a small repro case and attach the
output of (thread backtrace) with logging enabled (log enable lldb
unwind). We'll try to look at it.

thanks,
pl


On 13 November 2015 at 19:22, Eugene Birukov via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
> Hi,
>
> I am running on Ubuntu Linux. I am using a custom debugger built upon LLDB
> C++ API using version 3.7.
>
> The target program issues a lot of "legitimate" SIGSEGV signals that it
> handles itself. Its signal handler runs on a separate stack (it uses
> sigaltstack() and SA_ONSTACK). Now, sometimes a bug in the program causes
> SIGSEGV that the handler cannot deal with and it crashes. Now, when I load
> the core, I see stack frames for the signal handler stack, but what I really
> need are frames for the signaled stack.
>
> Of course, I have access to siginfo_t and ucontext_t, so I can try to use
> some unwind library, but that approach is far from ideal - the LLDB already
> has the unwinder. So, what should I do to get the set of SBFrame's that I
> can query about local variables, etc.? I mean, something like .cxr command
> in Windbg would be really handy...
>
> Thanks,
> Eugene
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to