Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!mozart.amd.com!proton!tim
From: tim@proton.amd.com (Tim Olson)
Newsgroups: comp.sys.nsc.32k
Subject: Re: Bug in minix library setjmp.s; lots of GNU tools diffs available
Message-ID: <1991Feb12.030148.23443@mozart.amd.com>
Date: 12 Feb 91 03:01:48 GMT
References: <9102072159.AA02808@halsoft>
Sender: usenet@mozart.amd.com (Usenet News)
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Austin, TX
Lines: 39

In article <9102072159.AA02808@halsoft>  writes:
| Ian writes:
| >Jyrki Kuoppala writes:
| > - When porting emacs to pc532-Minix, I noticed there's a bug in the
| > - setjmp library routine - it doesn't save registers r3-r7 (and f4-f7)
| > - which I think it should do.
| ...
| >I believe in ANSI C, there is no requirement to save registers in setjump.
| >Variables which have to be accessed after the setjump should be marked
| >volatile. Yes, some people have said that is ugly and nor the way it
| >should be done, but I pretty sure, that is the way it is!
| 
| I suspect that register variables ought to be preserved despite what the
| ANSI standard says, particularly since well optimized C compilers put
| everything they can into registers whether or not they are declared
| register.

Actually, the most "correct" implementation of setjmp/longjmp is to
ensure that all automatic variables, like statics and externals, have
the value they had at the time of the longjmp.  Saving register values
in the jmpbuf causes those that were actually in registers to have the
values they had at the time of the setjmp (but externals and
automatics not in registers have their longjmp value).  The reason the
ANSI standard specified that the values of non-volatile automatics are
not to be relied upon (how's that for a double-negative! ;-) is that:

	1) There exist "correct" implementations (VAX with
	   stack-unwind longjmp, register-windowed RISC processors).

	2) There exist "register save" implementations.

	3) Forcing one or the other to be the standard would be
	   prohibitive on various architectures.


--
	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)