Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!styx!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.arch
Subject: Re: subroutine frequency
Message-ID: <13286@sun.uucp>
Date: Fri, 13-Feb-87 16:56:03 EST
Article-I.D.: sun.13286
Posted: Fri Feb 13 16:56:03 1987
Date-Received: Sat, 14-Feb-87 23:01:51 EST
References: <1881@homxc.UUCP> <898@moscom.UUCP> <476@mntgfx.MENTOR.COM> <651@mcgill-vision.UUCP>
Sender: news@sun.uucp
Reply-To: guy@sun.UUCP (Guy Harris)
Organization: Sun Microsystems, Mountain View
Lines: 13
Keywords: register stack frame variable

>WHAT?!?!  I can't see any reason that longjmp can't get the registers
>back - if it can't restore them easily on that architecture then just
>have setjmp save them in the jmp_buf!  What's the problem?

The problem, to put it simply, is that if "longjmp" can't get the
values of the register variables *at the time the longjmp was
called* getting them from values saved by "setjmp" would restore the
values of the register variables *at the time the setjmp was called*,
which is NOT what the SVID (or various UNIX manuals) claim that
"longjmp" does.  On some architectures it is painful to try to get
the values as of the time "longjmp" was called; you can't just walk
the stack to find the values saved when the routine that called
"setjmp" last made a procedure call.