[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 <thorpej%me.com@localhost> wrote:
> > On Nov 21, 2021, at 6:35 AM, John Marino (NetBSD) <netbsd%marino.st@localhost>
> > 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
Main Index |
Thread Index |