Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

["John Marino (NetBSD)" <netbsd%marino.st@localhost>]

I'm not very familiar with CFA information.  I've been worried that
strip(1) removes those symbols.  Is that worry meritless?

On Sun, Nov 21, 2021 at 9:32 AM Jason Thorpe <thorpej%me.com@localhost> wrote:

>
> > On Nov 21, 2021, at 6:35 AM, John Marino (NetBSD) <netbsd%marino.st@localhost>
> wrote:
> >
> > Sorry, I meant to answer and got overwhelmed.
> > Actually, I had a typo in the previous response. I meant to say "GCC"
> unwinder, not gdb unwinder.
> > I don't see how this helps support the GCC unwinder.  The context
> information to support the unwind is already provided, we just need the
> boolean (is this a sigtramp frame?) to decide whether or not to use it.  I
> thought Uwe's suggestion to return the context was either an expansion for
> more general use or a second function.  All we have is the pc pointer.
>
> Well, getting back to a previous part of the conversation, there can be
> multiple kinds of contexts, either a “sigcontext” or a “ucontext_t”, and so
> telling you “it’s in a trampoline” isn’t necessarily useful — you need to
> know what kind it is.  The idea behind __sigtramp_unwind_np() is that you
> would need less architecture-dependent logic (and that the API would be
> future-proof, in case the way the handlers work changes for some reason).
>
> However, Joerg correctly pointed out that the real correct solution
> already exists, which is to say “make sure DWARF CFA information exists for
> signal trampolines”, which is what I’ve been focusing on over the last
> couple of weeks.  Only if that proves to be insufficient for some reason
> should we add a new non-portable API to assist unwind.  DWARF unwind
> information doesn’t really work for FreeBSD trampolines, because the
> handler is supplied by the kernel, and so of course there’s not really a
> good way to look up the CIE / FDE for it.
>
> -- thorpej
>
>