> Hi all.  pth-1.3.7 (the GNU portable thread library) doesn't work
> under 1.5_ALPHA; programs fail with a "longjmp botch." error message.

> I've looked at lib/libc/arch/vax/gen/__setjmp14.S, but I don't read
> VAX assembly.  It looks like before calling __sigreturn14,
> __longjmp14 walks up the frames of the current stack to where
> __setjmp14 was called, looking for spots where it has to copy out the
> longjmp return value?

Not quite.  What it is doing is unwinding the stack, returning from
each frame in turn, in order to get registers restored correctly.  The
reason it's fiddling with r0 and r1 is in case some stack frame saves
r0 and r1 - in that case it bashes the saved r0/r1 value with the value
it wants to have there.

> If so, this fails because pth will call longjmp with a totally
> different stack than the one that was active at setjmp time.  Can
> someone fill me in on why the VAX longjmp works this way?  Why can't
> it just do the equivalent of a __sigreturn14, no matter where it is,
> forcing the longjmp return value?

Because it has to restore any registers saved by intermediate call
frames (in the "normal" case, that is).  Arguably all registers should
be saved into the jmp_buf; I don't know why that isn't how it's done.

This is really two bugs.

One is a bug in pth - it's trying to abuse setjmp/longjmp as a
general-purpose context switch mechanism, which it just isn't.

The other is that the VAX longjmp can't ever work right, except by
luck, for jumping between stacks; if nothing else, it will instantly
botch out when jumping from a higher-addressed stack to a
lower-addressed one.

Unfortunately, I can't see how to fix the latter without (a) adding a
controlled, advertised way to switch between stacks and (b) giving up
the botch detection normally provided by the blssu seven isntructions
into the longjmp code.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B