pa,

I've been going through some of the glibc issues that we
have and trying to fix them... or put in a large enough shoe
-horn that the solution fits.

The following are two .dpatch's that I'd like to send to
gotom to get put in for -15 or -16 depending on how much
testing I get done.

The first .dpatch has to do with our jmpbuf implementation,
and the fact that division calculation is not always 
correct. I _think_ this is a solution, but since I'm away
this weekend, I challenge someone to put together a jmpbuf
test that tries to break this. I've been told that anything
using libst is prone to breakage on PA without some ugly
hacks (e.g. lurker).

The second .dpatch fixes our mcontext_t problem. I don't 
know what was going on with out rather wonky definition, but 
I'm probably sure it was just bitrot. I've specified that
a signal context _is_ just a machine context. Kernel and 
glibc are now in sync.

This brings up another issue! When passing the sigcontext
back from a 64-bit kernel, the kernel passes back 64-bit
values and the mcontext is rather useless to the signal
handler. This has _always_ been broken and has never worked
properly. I'm working on adding some rather ugly "#ifdef __LP64__"
code to arch/parisc/signal.c to have it translate the values
into a sigcontext32 that I have defined in sys32.h.
There are a few other examples in signal.c that already do
some rather ugly conversion :)

Suggested solutions:
- Widen sigcontext
- Add conversion code to signal handling path

I would rather do the later... since it doesn't change 
the way we do business across the board.

Ideas and input welcome and appreciated!

c.