Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
uwe, I don't know much about CFI attributes. I had just assumed that strip(1) would remove those symbols. Was that a bad assumption? I'm still not sure if GCC unwind can use them but if they are permanent and I took a look at gccgo, maybe it could work. John On Mon, Oct 18, 2021 at 12:41 PM Valery Ushakov wrote: > > On Mon, Oct 18, 2021 at 10:41:48 -0500, John Marino (NetBSD) wrote: > > > How we did it with libc before is shown in the netbsd-unwind.h link in > > the original post. This technique looks for __sigtramp_siginfo_2 > > assembly code but no longer works. I don't know how to do this any > > other way. GDB doesn't either, it uses the debug information to match > > the function name __sigtramp_siginfo_2 and I am not even sure that's > > valid for current NetBSD releases based on what we've learned here. > > Didn't kamil@ fixed this a while back? E.g. for amd64: > > revision 1.8 > date: 2020-10-12 20:55:54 +0300; author: kamil; state: Exp; lines: +29 -3; > commitid: sz57gQtWi3mGKDrC; > Decorate the x86_64 signal trampoline with CFI attributes easing unwinding > > Combine the approach provided by Nikhil Benesch and Andrew Cagney. > > Now, the unwinders (in gccgo, backtrace(3), etc) can unwind properly > the stack from a signal handler. > > Fixes lib/55719 by Nikhil Benesch > > -uwe
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
I'm in no way a GDB expert. I believe it's currently using basic dwarf debugging information, basically just looking for the __sigtramp_siginfo_2 function name. If it finds that, it declares the sigtramp found. I do not believe it's using the cfi notations which are relatively recent if I understand correctly. What this discussion has gotten me wondering regarding gdb is if looking for __sigtramp_siginfo_2 is still a valid method of detection on the newer NetBSD releases. The only reason I brought gdb up is because it's the other major user of KERN_PROC_SIGTRAMP sysctl so I thought NetBSD might benefit there too. John
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
On Mon, Oct 18, 2021 at 10:41:48 -0500, John Marino (NetBSD) wrote: > How we did it with libc before is shown in the netbsd-unwind.h link in > the original post. This technique looks for __sigtramp_siginfo_2 > assembly code but no longer works. I don't know how to do this any > other way. GDB doesn't either, it uses the debug information to match > the function name __sigtramp_siginfo_2 and I am not even sure that's > valid for current NetBSD releases based on what we've learned here. Didn't kamil@ fixed this a while back? E.g. for amd64: revision 1.8 date: 2020-10-12 20:55:54 +0300; author: kamil; state: Exp; lines: +29 -3; commitid: sz57gQtWi3mGKDrC; Decorate the x86_64 signal trampoline with CFI attributes easing unwinding Combine the approach provided by Nikhil Benesch and Andrew Cagney. Now, the unwinders (in gccgo, backtrace(3), etc) can unwind properly the stack from a signal handler. Fixes lib/55719 by Nikhil Benesch -uwe
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
> On Oct 18, 2021, at 9:41 AM, John Marino (NetBSD) wrote: > > yes, it sounds like a __in_signal_trampoline function would work for > the GCC unwind, and I would think it would work for GDB as well. Maybe I missed the GDB use case ... what is it that GDB needs to be able to do here? This hypothetical function would only be able to query "self", not another process, so if GDB needs to be able to do the check for another process (the debug target, presumably), then it will need to use something else (can't it use the CFI notations to do the unwind?) (Not all of the trampolines are correctly notated, but that's not a particularly tough problem to solve, either...) -- thorpej
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
yes, it sounds like a __in_signal_trampoline function would work for the GCC unwind, and I would think it would work for GDB as well. Thanks, John On Mon, Oct 18, 2021 at 10:48 AM Jason Thorpe wrote: > > > > > On Oct 18, 2021, at 8:41 AM, John Marino (NetBSD) wrote: > > > > For GCC, we've got the return address (context->ra in the unwind > > programs in the original post). The "problem" is that we want to > > know if that address falls on a signal trampoline frame. If NO, > > return "end of stack", otherwise unwind the frame. > > Seems like a non-portable libc function that could check among the various > candidates that libc knows about would not be terribly difficult. > > > A sysctl that returns an array of address pairs for all signal > > trampolines in the process is what I'm requesting. > > Would a function like (hypothetically-named) "bool > __in_signal_trampoline(uintptr_t addr);" provided by libc be workable for > your use case? > > > If there's another way to determine if an address falls within a > > signal trampoline, I'd like to see actual code to see if I can adapt > > it. > > Of course, the kernel team could just deny the request, but I won't be > > able to fix the regression caused when the per-signal trampolines were > > introduced. > > Thanks, > > John > > -- thorpej >
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
> On Oct 18, 2021, at 8:41 AM, John Marino (NetBSD) wrote: > > For GCC, we've got the return address (context->ra in the unwind > programs in the original post). The "problem" is that we want to > know if that address falls on a signal trampoline frame. If NO, > return "end of stack", otherwise unwind the frame. Seems like a non-portable libc function that could check among the various candidates that libc knows about would not be terribly difficult. > A sysctl that returns an array of address pairs for all signal > trampolines in the process is what I'm requesting. Would a function like (hypothetically-named) "bool __in_signal_trampoline(uintptr_t addr);" provided by libc be workable for your use case? > If there's another way to determine if an address falls within a > signal trampoline, I'd like to see actual code to see if I can adapt > it. > Of course, the kernel team could just deny the request, but I won't be > able to fix the regression caused when the per-signal trampolines were > introduced. > Thanks, > John -- thorpej
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
For GCC, we've got the return address (context->ra in the unwind programs in the original post). The "problem" is that we want to know if that address falls on a signal trampoline frame. If NO, return "end of stack", otherwise unwind the frame. The KERN_PROC_SIGTRAMP of FreeBSD and DragonFly has in its return structure a pair of addresses representing the starting address and ending address of that process's signal frame, so it's a simple matter of checking if context->fa falls between them. How we did it with libc before is shown in the netbsd-unwind.h link in the original post. This technique looks for __sigtramp_siginfo_2 assembly code but no longer works. I don't know how to do this any other way. GDB doesn't either, it uses the debug information to match the function name __sigtramp_siginfo_2 and I am not even sure that's valid for current NetBSD releases based on what we've learned here. A sysctl that returns an array of address pairs for all signal trampolines in the process is what I'm requesting. If there's another way to determine if an address falls within a signal trampoline, I'd like to see actual code to see if I can adapt it. Of course, the kernel team could just deny the request, but I won't be able to fix the regression caused when the per-signal trampolines were introduced. Thanks, John
