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