[pups] V7 setjmp/longjmp

[pups] V7 setjmp/longjmp

[bwc]

Looking thru the code for setjmp/longjmp (/usr/src/libc/gen/setjmp.s),
and have a question.  Longjmp seems to make an attempt at restoring
register two through four, but setjmp doesn't save them.  Where do
these register get saved from?

 Brantley Coile

[pups] V7 setjmp/longjmp

[Michael Davidson]

bwc at coraid.com wrote:

>Looking thru the code for setjmp/longjmp (/usr/src/libc/gen/setjmp.s),
>and have a question.  Longjmp seems to make an attempt at restoring
>register two through four, but setjmp doesn't save them.  Where do
>these register get saved from?
>
setjmp and longjmp are intimately familiar with the way in which
the standard stack frame for C functions is laid out

The stack frame itself is maintained by the functions csv and cret
which are defined in /usr/src/libc/crt/csv.s

The C compiler generates a call to csv at the start of each function:

    jsr    r5, csv

which has the net effect of saving the current value of r5 on the stack,
setting r5 to point to the saved r5, and saving r4, r3 and r2

and at the end of each function it generates:

    jmp    cret

which restores the values of r2 - r5 and returns to the function's caller.

Thus r5 is used as a frame pointer.

All that setjmp saves are the values of r5, sp and the return address.

When longjmp is called it walks back up the chain of frame pointers
pointed to by r5 until it gets to the frame immediately below the
one for the context it wants to return to. It then patches the return
address in that frame to be the return address saved by setjmp and
uses cret to restore everything (almost) as if setjmp had just returned.

Note that this means that r4, r3 and r2 get restored to the values
that they had at the time that the next stack frame was established
(ie when the "next" function down was called from the original context)
and that these are not necessarily the values that they had at the
moment when the original call to setjnp returned. Hence the various
caveats about not relying on the value of any register variables
after returning via longjmp.

[pups] V7 setjmp/longjmp

[Wolfgang Helbig]

Michael Davidson distrusted:
>Note that this means that r4, r3 and r2 get restored to the values
>that they had at the time that the next stack frame was established
>(ie when the "next" function down was called from the original context)
>and that these are not necessarily the values that they had at the
>moment when the original call to setjnp returned. Hence the various
>caveats about not relying on the value of any register variables
>after returning via longjmp.

You can trust register variables when setjmp() returns the second time. Then
the registers are restored to the values they had when the "next" function was 
called, that is the "values as of the time longjmp() was called" (quoted from
longjmp(3)'s man page. Thus any variable behaves the same, regardless of its
storage class.

By the way, this is not the case in V6. The register variables-- and only
the register variables-- are restored to the values as of the time setexit() was
called. (In V6 "setjmp()" is named "setexit()" and "longjmp()" is named "reset()").
Thus the value of a variable depends on its storage class. If it is register,
you get the value when setexit() was called, if it is not register, you get
the value when reset() was called. This might be considered a bug.

Greetings

Wolfgang

[pups] V7 setjmp/longjmp

[Michael Davidson]

Wolfgang Helbig wrote:

>Michael Davidson distrusted:
>
>>Note that this means that r4, r3 and r2 get restored to the values
>>that they had at the time that the next stack frame was established
>>(ie when the "next" function down was called from the original context)
>>and that these are not necessarily the values that they had at the
>>moment when the original call to setjnp returned. Hence the various
>>caveats about not relying on the value of any register variables
>>after returning via longjmp.
>>
>
>You can trust register variables when setjmp() returns the second time. Then
>the registers are restored to the values they had when the "next" function was 
>called, that is the "values as of the time longjmp() was called" (quoted from
>longjmp(3)'s man page. Thus any variable behaves the same, regardless of its
>storage class.
>
Yes, you are right - V7 restores the register variables to a state which
is consistent with the other auto variables in the function - ie the value
which they had when longjmp was called.

The caveats about not relying on register variables applied to V6.

[pups] V7 setjmp/longjmp

[Wolfgang Helbig]

>X-Unix-From: michael_davidson at pacbell.net  Tue Dec 31 17:04:50 2002
>Date: Tue, 31 Dec 2002 08:02:37 -0800
>From: Michael Davidson <michael_davidson at pacbell.net>
>User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4) 
Gecko/20011128 Netscape6/6.2.1
>X-Accept-Language: en-us
>MIME-Version: 1.0
>To: Wolfgang Helbig <helbig at Informatik.BA-Stuttgart.DE>
>CC: pups at minnie.tuhs.org
>Subject: Re: [pups] V7 setjmp/longjmp
>Content-Transfer-Encoding: 7bit
>
>Wolfgang Helbig wrote:

>>You can trust register variables when setjmp() returns the second time. Then
>>the registers are restored to the values they had when the "next" function was 
>>called, that is the "values as of the time longjmp() was called" (quoted from
>>longjmp(3)'s man page. Thus any variable behaves the same, regardless of its
>>storage class.
>>
>Yes, you are right - V7 restores the register variables to a state which
>is consistent with the other auto variables in the function - ie the value
>which they had when longjmp was called.
>
>The caveats about not relying on register variables applied to V6.

Nope, even in V6, register variables are restored to the values they had
when reset(III) was called! (reset() is the name of longjmp() in V6).
By the way, reset() is much smaller than longjmp() but provides the same
functionality.

I wonder why longjmp() was rewritten.

Wolfgang.

[pups] V7 setjmp/longjmp

[Dennis Ritchie]

Helbig remarked (quoting Davidson):

 > >Yes, you are right - V7 restores the register variables to a state which
 > >is consistent with the other auto variables in the function - ie the value
 > >which they had when longjmp was called.
 > >
 > >The caveats about not relying on register variables applied to V6.

 > Nope, even in V6, register variables are restored to the values they had
 > when reset(III) was called! (reset() is the name of longjmp() in V6).
 > By the way, reset() is much smaller than longjmp() but provides the same
 > functionality.

 > I wonder why longjmp() was rewritten.

Setjmp/longjmp do more (setjmp returns different values
for the initial call and the longjmp-invoked one).
But the thing that would become more important
is that the PDP-11 compiler's calling sequence was
especially friendly toward restoring register values--
it just worked automatically.

Other machines and compilers were not so friendly.
This is why ANSI and ISO had to put in special rules
about promising to preserve only things marked
volatile.

We've been through this before.

	Dennis