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 <thor...@me.com> wrote: > > > > On Nov 14, 2021, at 3:12 PM, John Marino (NetBSD) <net...@marino.st> > 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 > >