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 <thor...@me.com> wrote: > > > On Nov 21, 2021, at 6:35 AM, John Marino (NetBSD) <net...@marino.st> > 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 > >