[openssl-dev] OpenSSL 1.1.0 pre 5+6: SPARCv9 assembler stack alignment problem

[Andy Polyakov]

> When building OpenSSL 1.1.0 pre 5 or pre 6 on Sparc I get:
> 
> /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 4811: warning:
> stack alignment problem; second operand is not a multiple of 8
> /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5063: warning:
> stack alignment problem; second operand is not a multiple of 8
> /usr/ccs/bin/as: "crypto/ec/ecp_nistz256-sparcv9.s", line 5539: warning:
> stack alignment problem; second operand is not a multiple of 8
> 
> The lines in question in crypto/ec/ecp_nistz256-sparcv9.s are:
> 
>  save %sp,-(2047+192)-32*10,%sp
>  save %sp,-(2047+192)-32*18-32,%sp
>  save %sp,-(2047+192)-32*15-32,%sp
> 
> They probably go back to the following lines in
> crypto/ec/ecp_nistz256-sparcv9.s.S:
> 
> ...
> #ifdef  __arch64__
> .register       %g2,#scratch
> .register       %g3,#scratch
> # define STACK64_FRAME  STACK_FRAME
> # define LOCALS64       LOCALS
> #else
> # define STACK64_FRAME  (2047+192)
> # define LOCALS64       STACK64_FRAME
> #endif
> ...
>         save    %sp,-STACK64_FRAME-32*10,%sp
> ...
>         save    %sp,-STACK64_FRAME-32*18-32,%sp
> ...
>         save    %sp,-STACK64_FRAME-32*15-32,%sp
> 
> I can't judge on the validity of the "stack alignment problem", but at
> least 2047 is indeed not divisible by 8 (but all other offsets added or
> subtracted from 2047 are).

Thing there is following. If if have close look you'll notice that those
functions are VIS3 ones. They use 64-bit multiplication and addition
instructions. Normally you can't use them in 32-bit application context,
because higher halves of most registers are not preserved upon context
switch or trap delivery. But there is one special thing about stack in
64-bit[!] application context, namely that it's biased by 2047 bytes.
Yes, %sp in 64-bit application is actually misaligned. Linux kernel was
modified to recognize misaligned stack *even* in 32-bit application
context and preserve full registers' contents, which makes it possible
to use faster code path even in 32-bit application (it's discussed in
commentary section in bn/asm/sparct4-mont.pl. Solaris doesn't recognize
misaligned 32-bit stack, corresponding capability bit in never set, and
code is never called. In other words warning is benign. Since you
haven't seen similar warning from sparct4-mont module I suppose
assembler looks one at save instruction. This in turn should mean that
it's possible to work around it...