This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ARM setjmp and r12


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]