Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!cs.tcd.ie!tcdmath!ch
From: ch@maths.tcd.ie (Charles Bryant)
Newsgroups: comp.lang.c
Subject: Re: Behaviour of setjmp/longjmp and registers
Message-ID: <302@maths.tcd.ie>
Date: 26 Jan 89 21:09:11 GMT
References: <8812@alice.UUCP> <1989Jan23.190446.8559@utzoo.uucp> <5771@phoenix.Princeton.EDU>
Reply-To: ch@maths.tcd.ie (Charles Bryant)
Organization: Maths Dept., Trinity College, Dublin
Lines: 44

In article <5771@phoenix.Princeton.EDU> haahr@princeton.edu (Paul Gluckauf Haahr) writes:
>a setjmp/longjmp implementation that restores all variables (including
>those in registers) falls out of a caller saves function call protocol.
>no muss, no fuss, just restore the stack pointer and pc.  this will
>work in the presence of inter-procedural optimization, if setjmp() is
>marked as a function that trashes all registers.
>

Could you explain this further please. Consider the example:

	foo()
	{
		register a,b,c;
		/* useful work with a,b,c so all are live */
		if (setjmp(jb)==1) { something using a, b, and c }
		a += b+c;
		fna();		/* only a is live */
		return a;
	}

	fna()
	{
		longjmp(jb,1);
	}

Then the stack will look like this:

call to setjmp: <addr in foo> a b c <addr foo will return to>
call to longjmp: <addr in fna> <addr in foo> a <addr foo will return to>

setjmp can't know what registers were saved (i.e. a, b, c) so it must save
the sp as the address where a is saved.
if longjmp restores the sp to this value, 'foo' will assign
a = <addr in fna>
b = <addr in foo>
c = a at time of longjmp

Is this reasoning correct? Does the compiler have to save ALL the registers for
every function call in 'foo' which potentially could call longjmp or is in
a different file?
-- 

		Charles Bryant.
Working at Datacode Electronics Ltd.