On Sun, Mar 04, 2018 at 02:57:38PM +0100, Eric Botcazou wrote: > > I can't argue with anything in that comment, other than the conclusion. :-) > > It's not the compiler's job to implement the setjmp/longjmp save/restore. > > Maybe Kenny was working around a problem with some target's buggy setjmp > > and spilling everything "fixed" it? > > What are the requirements imposed on setjmp exactly and by whom? The psABI > on > SPARC (the SCD) has an explicit note saying that setjmp/sigsetjmp/vfork don't > (have to) preserve the usual non-volatile registers.
C11 says in 7.13.2.1/2 "The longjmp function restores the environment saved by the most recent invocation of the setjmp macro in the same invocation of the program with the corresponding jmp_buf argument." where "environment" is not really defined, but it includes all information a program will need to return to its caller (so it has to restore the non-volatile registers, set stack pointers correctly, that kind of thing). But there is 7.13.2.1/3 as well: "All accessible objects have values, and all other components of the abstract machine have state, as of the time the longjmp function was called, except that the values of objects of automatic storage duration that are local to the function containing the invocation of the corresponding setjmp macro that do not have volatile-qualified type and have been changed between the setjmp invocation and longjmp call are indeterminate." So, an auto var that is *not* changed between setjmp and longjmp has to keep its value. If the auto var lives in memory that works out fine; if it lives in a non-volatile reg and setjmp saves those, that works as well; but if it lives in a *volatile* register it does not (because it might be moved to some other reg for example; in the abstract machine that did not change anything, but in the real machine it does). If setjmp clobbers everything a function call does, this still works fine as far as I see. And GCC gives warnings if not (not that that makes things compliant). Segher
