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

[Rainer Jung]

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).

Thanks and regards,

Rainer

[Andy Polyakov]

Post by Rainer Jung
stack alignment problem; second operand is not a multiple of 8
stack alignment problem; second operand is not a multiple of 8
stack alignment problem; second operand is not a multiple of 8
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
...
#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...