> On Oct 15, 2021, at 1:19 PM, Valery Ushakov <u...@stderr.spb.ru> wrote: > > On Fri, Oct 15, 2021 at 23:14:39 +0300, Valery Ushakov wrote: > >> On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote: >> >>> Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl? >> >> It's been ages since I touched this area, but don't we have >> per-sigaction trampolines? I mean, in practice they all use the same >> __sigtramp_siginfo_$version trampoline, that sigaction passes to the >> actual syscall, but in principle the process can have different >> trampolines for different signals, can't it? >> >> struct sys___sigaction_sigtramp_args { >> syscallarg(int) signum; >> syscallarg(const struct sigaction *) nsa; >> syscallarg(struct sigaction *) osa; >> syscallarg(const void *) tramp; // <- >> syscallarg(int) vers; >> }; > > PS: We used to have a trampoline that the kernel copied out into the > process address space (bottom of the stack, iirc) - and that would be > something for KERN_PROC_SIGTRAMP to return indeed. But that was like > before netbsd 2.0, iirc.
Right, that was The Very Old Way. There is an API contract between libc and the kernel vis a vis the signal trampoline, but the trampoline itself is in libc, which could get mapped anywhere. So there is not a single static address that could be returned, even per-process, because, as uwe points out, the trampoline can be specified on a per-signal basis (there is one for "siginfo" signal delivery and another for the old-style "sigcontext" signal delivery). -- thorpej