If strip removes it, then you’re doomed anyway and trampoline assist via a function won’t help you, because you won’t be able to get to the trampoline or past it anyway.
-- thorpej Sent from my iPhone. On Nov 21, 2021, at 7:54 AM, John Marino (NetBSD) <netbsd%marino.st@localhost> wrote:
I'm not very familiar with CFA information. I've been worried that strip(1) removes those symbols. Is that worry meritless?
> 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
|