Versioning longjmp etc.

[Steve Munroe]

Need start over on this ...

Ulrich Drepper writes:

> Steve Munroe wrote:
> > We are looking at integrating Vector Extensions (AKA Altivec or VMX) 
into 
> > glibc for PPC32/PPC64.
>
> Why should this be necessary?  It makes almost no sense at all to
> include the content of these registers in the state. ...

Because the ABI requires it. 
<ftp://ftp.linuxppc64.org/pub/people/sjmunroe/PPC64-VMXabi.txt.gz>

VMX is treated like any other (GPRs, FPRs) register file. The ABI 
specifies volatile and nonvolatile registers. Volatile registers are saved 
by the caller (if it needs to preserve them) and nonvolatile registers are 
"callee saved". With this definition setjmp/longjmp need to save and 
restore the nonvolatile registers, including the nonvolatile vector 
registers (v20-v31 and vrsave). VMX state is included only if indicated in 
the AT_HWCAP. This will be handled similar the way AT_DCACHEBSIZE was 
interrogated for powerpc memset.

> ... setjmp/longjmp are
> probably never used in the middle of computations in which vector
> registers are used.

That is difficult to enforce in the general case. As applications get 
larger and more complex  a single application may use a mixture of VMX and 
non-VMX aware libraries. With call-backs the stack can easily include 
non-VMX aware functions sandwiched between VMX aware layers. If this 
middle(ware) layer gets control as the result of a signal and longjmp, the 
VMX state must be restored before it returns to the initial VMX-aware 
layer. Since the compiler (and code generated by it) was not VMX-aware, we 
must depend on the runtime code (setjmp/longjmp).

Steven J. Munroe
Power Linux Toolchain Architect
IBM Corporation, Linux Technology Center