This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: ARM setjmp and r12
- From: "Schwarz, Konrad" <konrad dot schwarz at siemens dot com>
- To: "Nick Clifton" <nickc at redhat dot com>
- Cc: "Shaun Jackman" <sjackman at gmail dot com>, <newlib at sources dot redhat dot com>
- Date: Tue, 2 May 2006 10:51:46 +0200
- Subject: RE: ARM setjmp and r12
> 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