tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

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 <> wrote:

> > On Nov 21, 2021, at 6:35 AM, John Marino (NetBSD) <>
> 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

Home | Main Index | Thread Index | Old Index