This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Is "longjmp" SAFE?

Other Parts Discussed in Thread: TMS320C6748

I have a question about "setjmp.h".(I worked on TMS320C6748)

I have read compiler user manual.

In Manual, It said, All register except scratch registers(A10~A15, B10~B15), if it still be used after a function call. The Caller will protect them before making a fuction call, and the register content will restore by Caller on sub-function returns. All of these register A0~A9, B0~B9, & A16~A31, B16~B31 can be used free in Callee function, is that right?

thake the viewpoint of longjmp progress:

Step1. setjmp() ........stored scratch register group into a "jmp_buf" (and a return address.)

Step2. when longjmp() happens, scratch register's contents is auto-recovered.

Step3. longjmp() finally set B3(or B4? function return address register) to the next code line just after setjmp(),

Step4. It seemd It's up to C Compiler take care of other register variable 's recovery,  is that right?

  • Two things:

    • When setjmp() is called, it looks just like a normal function call, which causes the caller to save A0-A9, etc. so there is no need for setjmp() to save those registers.
    • You must declare as volatile all local variables which must be valid when longjmp returns.  (This is a requirement of the C standard.)
  • To: Archaeologist

              thanks for your post.

              If all register variables has restored yet ( to them original value before making a sub function call),
              why I still need mask them as volatile ?

  • Because the values in A0-A9, etc. that get saved for the call site to longjmp might not be the values that were originally in those registers at the time of the call to setjmp.

    The C standard explicitly requires it.  C99 says (C89 has similar text), in section 7.13.2.1 "The longjmp function", paragraph 3:

    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.

    In short, if you have a local variable var (which might live in a register), followed by a call to setjmp, followed by a write to var, followed by a longjmp, the value you write to var may or may not have been lost.  If you care about the value of var when longjmp is taken, you must declare it volatile.