There are a few things I think need to be addressed before the
nathanw_sa branch is brought down to the mainline.

First of all, we have an ABI issue with signals and debuggers.

Right now, the nathanw_sa branch has one signal trampoline for both
legacy "sigcontext" and POSIX "siginfo" handlers.  In the "siginfo"
case, the third argument is a pointer to a ucontext_t.  The ucontext_t
does not have the same layout as the sigcontext structure.

Debuggers need to grovel through the sigcontext in order to trace back
through signal handlers.  Yet, the debugger currently doesn't have any
way to know if the 3rd argument to a handler is a sigcontext or a
ucontext_t.

To solve this problem, I would like to move the signal trampoline out
into user space, into libc.  If we do this, then signal trampolines will
have a debugger-visible name (the symbol in the library), and can make
decisions based on the name.

I would like to propose the following names:

	__sigtramp		legacy signal trampoline like we
				currently set up in the kernel on
				the top of the user stack

	__sigtramp_siginfo	trampoline used for SA_SIGINFO signals

When we support RT signals, we can have __rtsigtramp versions of these
names.

The trampoline for any given signal would be passed up as an additional
argument to a new "sigaction" system call.  Old binaries which don't
provide a trampoline will get the legacy top-of-stack trampoline provided
by the kernel.  Support for this can be conditional on COMPAT_NETBSD16.

Putting the signal trampoline in libc has other benefits, like being able
to turn off execute permission on the stack via a sysctl and still have
program that use signals continue to work.

The other thing on my list: libsyscall has to go.  Some other imposition
mechanism for cancellation points needs to be found.  However, this only
blocks the libpthread bits, not the kernel bits.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>