Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

["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.

In the original post, I provided two implementations (current freebsd,
former netbsd) of the gcc unwinding.  Maybe I'm missing how
__sigtramp_unwind_np is supposed to be used there.  All I was asking for
was to pass pc (context->return_address) and get a boolean answer if it
were inside a signal trampoline.  The rest is already done.
Thanks,
John


On Sun, Nov 14, 2021 at 6:04 PM Jason Thorpe <thorpej%me.com@localhost> wrote:

>
>
> > On Nov 14, 2021, at 3:12 PM, John Marino (NetBSD) <netbsd%marino.st@localhost>
> wrote:
> >
> > So for the purpose of the gdb unwinder, I would pass NULL for the sp
> argument?
> > The unwinder would only be checking the result to see
> __sigtramp_unwind_np returns null or not.
>
> This would not work for the gdb unwinder — it only works for unwinding
> from within the same process, so for exception handling, etc.  I.e. if the
> unwinder in the compiler runtime wasn’t able to process the DWARF call
> frame info for the signal trampoline, for example.  The gdb unwinder may
> have to operate on a process that’s no longer running (and, at the very
> least, is not the current process), so it needs to rely only on DWARF call
> frame info and/or heuristics based on the symbol name (which I added to gdb
> quite some years ago now).
>
> The requirements for using this are:
>
> ==> In the frame that represents the handler itself, you are able to get
> the return address the handler will return to.
>
> ==> In that same frame, you can compute what the stack pointer should be
> when the handler returns (by either inspecting the instructions in the
> function prologue that setup the handler’s stack frame, or by parsing the
> DWARF call frame info).
>
> It’s that return address and stack pointer that you would pass to
> __sigtramp_unwind_np().
>
> Then the context returned by __sigtramp_unwind_np() would allow you to
> then get the stack pointer, PC, etc. for the context that would be resumed
> after the handler returns (because remember, signals can run on their own
> stack).
>
> So, this is a little more than just “is this PC in the signal
> trampoline?”.  This is “If this PC is in the signal trampoline, then return
> a pointer to the context that will be restored when the signal returns,
> given this SP.”  This was uwe’s suggestion.
>
> I can still expose just __sigtramp_check_np(), but the assumption was that
> you would use a “YES!” result from that to to off an find the
> context-to-restore… so we decided to encapsulate some of that work for you
> as well.  Does that make sense?
>
> If that assumption about how you would use __sigtramp_check_np() is
> invalid, please let me know so I can adjust the proposal.
>
> -- thorpej
>
>