> > 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.

setjmp/longjmp aren't required to preserve general registers; that's
why setjmp(3) says that values of all non-volatile autos modified
between the setjmp and longjmp are unpredictable.  

> 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.

For sure, it isn't what you're supposed to use setjmp for.  I think
pth deserves some leeway, though, because being a portable thread
library with almost no MD code isn't easy.

> 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.

Is this botch detection critical?  Can longjmp be relaxed to just move
to the target stack right away and not care?  This is what i386 and
m68k do.

Matt

--
Matt Fredette
fredette@aquery.com, fredette@mit.edu, fredette@theory.lcs.mit.edu
http://mit.edu/fredette/www
"If you understood everything I said, you'd be me."  - Miles Davis