> 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
