RE: ARM setjmp and r12

["Schwarz, Konrad" <konrad dot schwarz at siemens dot com>]

> Hi Konrad,
> > Because I have libraries delivered by different vendors who 
> compiled 
> > against different implementations of the C library.  The 
> whole point 
> > of an Application _Binary_ Interface is (at least for me) 
> to be able 
> > to link together relocatable (or shared) object (i.e., 
> binary) files, 
> > without regard to the header (i.e., non binary) files they were 
> > compiled with.
> 
> True.
> 
> > Note that the architecture-specific supplement to the SysV 
> ABI defines 
> > the layout of every structure (and also the name of every external) 
> > provided by the standard libraries.  See e.g.,
> > 
> http://www.stanford.edu/class/cs140/projects/pintos/specs/sysv-abi-i38
> > 6- 4.pdf, figure 6-76 (pg 157): <setjmp.h>.  (I agree that the 
> > information there is ambiguous, since the location of each 
> register is 
> > not defined within the array holding the registers, but it is with 
> > regards to the size of that array).
> 
> Right, but that is the supplement for the i386 and not the 
> ARM.

It was just an example (but the canonical one).

>  The only information I could find regarding the size of 
> the setjmp array for the ARM was in the "C Library ABI for 
> the ARM Architecture":
> 
>    www.arm.com/miscPDFs/8032.pdf
> 
> Where in section 5.11 it says:
> 
>    "The type and size of jmp_buf are defined by setjmp.h.  
> Its contents
>     are opaque, so setjmp and longjmp must be from the same 
> library, and
>     called out of line.

This is interesting, because C89 requires setjmp() to be a macro (that
in ARM presumably resolves to an identifier with external linkage of the
same name).

>     The link-time constant __aeabi_JMP_BUF_SIZE gives the 
> actual size of
>     a target system jmp_buf measured in 8-byte double-words.
> 
>     When _AEABI_PORTABILITY_LEVEL != 0, the required definition of
>     jmp_buf cannot be used to create jmp_buf objects. 
> Instead, a jmp_buf
>     must be passed as a parameter or allocated dynamically.

This is funny.  No code I have ever seen does this, it also is not C
standard conformant, thus making _AEBI_PORTABILITY_LEVEL != 0 fairly
useless.

Why didn't they just define jmpbuf large enough to cover all possible
cases/uses (e.g. all GP registers + PSR, etc.)?

Regards,

Konrad