This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: ARM setjmp and r12
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: "Schwarz, Konrad" <konrad dot schwarz at siemens dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, Shaun Jackman <sjackman at gmail dot com>, newlib at sources dot redhat dot com
- Date: Tue, 02 May 2006 13:59:37 +0100
- Subject: RE: ARM setjmp and r12
- References: <ECDC9C7BC7809340842C0E7FCF48C393EFCBED@MCHP7IEA.ww002.siemens.net>
On Tue, 2006-05-02 at 09:51, Schwarz, Konrad wrote:
> > 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).
>
No, c89 does NOT require setjmp to be a macro, it simply says that it
may be, and further that if it is then #undef'ing that macro is not
permitted. That's very different from requiring it to be a macro.
> > 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.)?
You need to think about the non-sysv environments where ARM is used, and
the purpose behind _AEABI_PORTABILITY_LEVEL. The intent of the
portability layer is to permit those who really want to compile
libraries for operation in multiple execution environments, and who are
prepared to accept a certain coding penalty for doing so, to get a level
of standardisation from the various C library environments that exist.
We've tried standardizing things like the setjump buffer in the past and
they've all failed because different execution environments have
fundamentally conflicting constraints. In the deeply embedded space,
for example, making jump buffers 24 double-words in size when you only
have 8 words in total to save is completely unacceptable. But on the
other hand, restricting the jump buffer to 8 words makes it unusable in
a sysv enviroment with VFP or iWMMX.
The solution was to provide a subset of the library and a mechanism to
write portable code. Doing so means you have to code your application
to the portability standard and you can't exploit everything that the
ISO C standard normally grants you. The idea is that ANY C library can
implement the portability layer at little or no cost (most of it can be
done by defining a few more symbols in the library).
R.