Re: avoid unnecessary register saves for setjmp

[Richard Earnshaw <rearnsha@arm.com>]

> > In the EABI we've been developing for the ARM we've been very careful to 
> > say that only the setjmp and longjmp functions can know the contents and 
> > layout of a jmp_buf.  This allows a function to use co-processor registers 
> > that are call saved and to be used in the middle of a call sequence 
> > without upsetting any other conforming code.  Hence only the C library 
> > needs to know the list of co-processors that are in use (and it is 
> > entitled to enter into other private conspiracies to determine the 
> > registers that need to be saved.  We've even designed the EH 
> > implementation in a way that will allow this to work as well (the unwinder 
> > will only try to execute instructions to access a particular co-processor 
> > once it has found a description of that co-processor in the unwind list).
> 
> How do you intend to implement this in practice?  I'm not concerned
> with the contents or layout of a jmp_buf; conforming programs can't get
> at them.  But user programs declare jmp_buf, which implies that they
> know its size.  And there's no way I can think of to dynamically
> allocate additional space if the jmp_buf is insufficiently large.
> Are you simply defining a very large jmp_buf for expansion?
> 
> This is the problem I encountered on both PowerPC and ARM.  I'm very
> curious to hear any solutions to it.

There's never a perfect solution to a situation like this.  The failure of 
history (and more recently of language standards bodies) to recognize that 
portable binaries have as much importance as portable source means that in 
the dark corners you are always doomed to failure.

The way we've approached the issue for the "ABI for the ARM Architecture" 
is to define a compliance model.  The model is fairly simple and basically 
divides into 2 categories.

In the "portable object" category, the trade-off is in the direction of 
portability over outright compliance to the language standards and 
performance.  Sometimes it's necessary to write your source code using a 
particular idiom in order to achieve maximum portability.  In other cases 
constants that the C standard says are compile-time literals may only be 
available as link-time constants.  You are also restricted as to the 
library functions you may call.  In general, for example, you can't 
include stdio.h in a portable object and have it do anything useful.  We 
believe that developers targeting the portable-objects market will be 
prepared to live with the restrictions because it's better than anything 
they could have otherwise.

In the "platform object" category, the trade-off is in the direction of 
compliance to the relevant standards.  You can use the full features of 
the language, but your object is tied to a particular platform.

setjmp is one of those functions that lies on the boundary between the two 
models.  If you are compiling for a particular platform, which has a 
strict ABI, then you can use a jmp_buf that is exactly right for that 
platform.  But if you are building a portable object, you have to be 
prepared to handle platforms with a lot of registers that need saving and 
restoring; it is however, possible to err on the side of caution and just 
say that any static jmp_buf must be at least as large as the jmp_buf used 
by any supported target system.  For a dynamic jmp_buf, if you are 
prepared to use dynamic allocation, and to use source-code modifications, 
then we've added a link-time constant that will tell you the exact size 
needed for the platform the code ends up running on.

As for the portable static size of a jmp_buf, we looked at the likely 
register needs given the current co-processor blocks in existence today, 
and concluded that we currently should allow for 32 double-words of memory 
(256 bytes, 8-byte aligned) for the buffer.  We've no proof that we will 
never need more, but sometimes you just have to make a judgement call.

We'd recommend that developers defining new open-platform ABIs use the 
portable size, since it then gives them maximum defence against future 
processor trends.

R.

Disclaimer: the ABI for the ARM Architecture" is still in draft form, so 
any specifics cited above may still be subject to change.  I don't expect 
them to, but the possibility does exist.