> > setjmp.S and _setjmp.S were modified to save the full 128 bit floating
> > point registers instead of only the 64 bit portion of the registers.
> 
> Both Linux and Android
> 
> * Save x19-x30 + sp (x31)
> * Save d8-d15 (so only the 64-bit portion of the registers)
> * Do not save fpcr.
> 
> I don't think we should deviate from that unless we have a good reason
> to do so.

Agree.

> I also think we should make jmpbuf fully opaque, and simply remove the
> _JB_XXX constants from <machine/setjmp.h>.

Indeed.  Some study of the ports tree happened last year.  Only a few
programs use the fields, and inside #ifdef OS + #ifdef ARCH fields,
typically as hand-built thread API or a debugging/inspection method.
Very few cases of this, generally in very old code.  If I recall only
a few did modification of SP and PC, others did inspection of SP, PC,
and "first argument".

No need to extend such support to new architectures.

> The plan is to "encrypt" the contents of jmpbuf so users shouldn't be
> messing around with its contents.

xor safety is now enforced on most architectures.  That's paving the
way for us to be sure we can do authentication or encryption. Auth
would entail replacing the two-value xor with something like a hmac,
but still exposing the registers for inspection by
debugging/inspection methods.  Encryption would hide the values on the
stack further, not sure what the gain would be yet.  The difficulty is
that this is written in asm, and painful to get right.

> It'd be good to document the layout somewhere in the source code
> though, e.g. in setjmp.S.

If _JB-XXX fields disappear from .h files, then the layout is only
handled inside the .S file.  Correct place to document it, if the asm
doesn't make it clear.

> If we want, I think we can adjust the size of jmpbuf.  No formal
> release yet and I don't think it's a difficial ABI break to overcome.

Our base uses so few setjmp calls, so an ABI break in this area is
really inexpensive, just get through a build and it's done.

Dale, please look at the xor handling in .S files on other architectures.

Reply via email to