Adjust how we handle allocating an SA Event structure used to inform
the application that we are blocking.

Since we only generate BLOCKED upcalls when the thread "on" the
vp blocks and further since the first thing we do after this is
run the upcall delivery code (we switch to the lwp lying around for
this very purpose), we will never generate more BLOCKED upcalls than
we have vps. We have an invariant, let's use it.

So we add a pointer to the vp structure, and store an upcall event
data structure in it. When we block in sa_switch(), we use that
structure. When we deliver an upcall into userland, if our vp is
lacking an upcall event structure, we don't free the upcall
event structure for the event we just delivered, we instead hang it
off of the vp.

We thus no longer need to allocate memory when blocking.

This version of the code contains a panic() in the case that we do
not have an upcall event structure available in sa_switch(). Keep this in
mind before putting this version into a production environment.

It has been suggested that it would be easier to embed an upcall event
structure in the virtual processor structure, given the invariant above.
The problem is that while we only can generate one BLOCKED per vp, we
do not necessarily deliver that upcall immediately to userland. If there
were pending upcalls, we deliver them first. As such, we can have code
running on the vp before the BLOCKED event is delivered. If _that_ code
blocks, we have no where to store that information. Thus we limit ourselves
to holding a pointer to separately-allocated memory.
Add sa_critpath_{enter,exit}(). These routines are intended to
permit code outside of kern_sa.c to indicate that it is entering
a code path in which any blocking (tsleep()) should NOT trigger
a BLOCKED upcall to userland. These should be used in areas where
we can't really start another thread, such as in context switching.

All these routines do is clear L_SA if it's set & put it back if
it had been set. Their main purpose is stylistic. Any routine could
just fiddle with L_SA, but these routines offer a way to separate
the abstract "Don't interrupt what I'm doing" from the exact implementation
of fiddling with L_SA.

Existing code not in kern_sa.c that twiddles L_SA should be converted
to use these routines.
Check in a work-in-progress sys_sa_preempt().

The idea is to fire off a user upcall on the given lwp. Then when it
gets delivered, libpthread will be able to do something with the
thread.

Needs a way to fire off an IPI if the thread is running on another
CPU.
Add a lot of comments to explain what routines are doing, and to
start documenting what locks are expected on entry, what locks are
held/released on exit, and what locks are taken internally. Hopefully
I understood things correctly.

I only got as far as sa_switch(), but I don't want to have these changes
linger just in my tree.
Fix a couple of tyops.
Add support for SA pthreads to gdb6.

Code from Nathan Williams, PR/35540 and me.

This could with more testing.
Fix up sys_sa_preempt so that this file compiles.
Add more comments.
Catch up with now-somewhat-dated netbsd-4. These changes took longer
than expected for me to actually get around to merging.
Update to today's netbsd-4.
Add files missed in last merge.
Pull in more files missed in bind merge.
Sync w/ NetBSD-4-RC_1
Enable the gdb/pthreads stuff on i386.
Check in first step towards having pthread_kill() kill a thread running
on another CPU.

This change adds initial support for deferred signal handling. Just before
we go to sleep and while we hold &self->pt_statelock, check to see if we
have any deferred signals (blocked signals) pending. These are signals
that are not masked in our mask and which have been sent to us. We
were running when they came in. Further, since they are being handled
this way, there's a signal handler defined for them.

So unlock, run the signal handler(s), then carry on.

For condition variables, we consider this a spurious wakeup, so we just
return 0, having not unlocked the mutex. We run the handler with
the mutex held. This shouldn't matter, as you aren't supposed to play
with mutexes in signal handlers. :-)

For nanosleep(), we just process signals, then go to sleep.

For all other cases, we are in a loop with some external predicate. So
we process the signal then roll around the loop to see if it still applies.

In sched_yield(), spin until all deferred signals are gone. Since we hold
self->pt_statelock and that lock has to be held before sending a deferred
signal, no new deferred signals will come in until we're asleep.

While here, be more careful about locking while changing pt_state
to PT_STATE_RUNNING. Grab pt_statelock while doing it, and also set
next->pt_vpid to self->pt_vpid holding the same lock. Will make
the test to determine how to deliver a signal work right (since
a thread's vpid will soon matter in the general case). No longer
set next->pt_vpid in pthread__next().
While examining the target's state, grab the target's statelock,
not our own.
Commmit some work in progress

- enable gdb6 on all architectures
- add support for amd64 crash dumps
- add support for /proc pid to executable filename for all archs
- enable thread support for all architectures (mips doesn't build)
- add a note section to kernels for the subset of platforms that have
  this enabled in -current.
Sync with somewhat-recent netbsd-4.
Catch up with netbsd-4.
Rename pt_blockedlwp to pt_lastlwp, and set it whenever we switch
to a new pthread. This way we always know on what lwp a given
thread is running.