Andy Polyakov wrote:
The problem was the setting for "linux64-sparcv9" within Configure.
Minimum change needed to fix problem:
SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
BF_PTR:::des_enc-sparc.o fcrypt_b.o
i.e. the addition of DES_INT is enough to fix the problem.
The following code should probably be added to the
crypto/des/destest.c around line 354 (at the start of main()) since
AFAIKS DES_LONG must always be exactly 4 bytes long no matter what
platform you are on;
No. DES_LONG can be 8 bytes too. Having it 4 bytes is preferable because
it provides better cache locality, but it's not absolute requirement.
You're likely suffering from compiler bug. Try to drop optimization
level or another compiler version. Even though adding DES_INT makes
sense it's inappropriate to add it to 0.9.8, because doing so would
break binary compatibility. DES_INT is therefore added to HEAD
development branch only. A.
I don't think it is a compiler bug, FYI it was GCC 4.1.2 which is pretty
recent 20061115.
From what I remember all DES_INT does is make the definition a DES_LONG
an "unsigned int" as opposed to an "unsigned long" (which is 64bit on
the linux64-sparcv9 platform).
From what I see if you make sizeof(DES_LONG) != 4, then "struct DES_ks"
size increases to 16 bytes which according its comment is plain wrong.
I'm not at all sure on your cache locality point, normally this only
comes into play when you talk of sizes a little bit bigger than the
machines natural integer width. Since a cache-line can be bigger than
the machines natural integer width and therefore you get cache locality.
You then claim that 4 bytes is preferred, but almost all systems that
OpenSSL targets; that have cache have a natural integer width of 32bit
or wider; so claiming 4 is preferred sounds like nonsense to me.
The ./Configure settings for "linux64-sparcv9" use the GCC options "-m64
-mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall" you
will see from my information below the inclusion of "-m64" makes
sizeof(long) = 8 and sizeof(void *) = 8 for a 64bit userspace ABI.
The main difference between 0.9.7 and 0.9.8 is the use of a SPARC
assembler file to build des_enc-sparc.S. If it can mathematically work
on 64bits better than 32bit at a time thats great, if not then its only
the ABI related differences in the code that change to get the data in
and out.
Sparc has 3 ABI modes for Linux:
__sparc_v8__ = Compatibility with 32bit only CPUs, kernel maybe 32bit
only or 64bit with dual support, userspace is 32bit, sizeof(int) = 4,
sizeof(long) = 4, sizeof(void *) = 4. This is called the "V8 ABI", GCCs
default mode with no extra options on most linux distros, or you may use
"-m32".
__sparc_v9__ && !__arch64__ = Compatibility with 64bit only CPUs,
kernel always 64bit, userspace is 32bit, sizeof(int) = 4, sizeof(long) =
4, sizeof(void *) = 4. This is commonly called "The V8PLUS ABI", GCC
needs "-mcpu=ultrasparc".
__sparc_v9__ && __arch64__ = Compatibility with 64bit CPUs, kernel
always 64bit, userspace 64bit, sizeof(int) = 4, sizeof(long) = 8,
sizeof(void *) = 8. This is called the "V9 ABI", GCC needs "-m64"
If you specify both "-m64" and "-mcpu=ultrasparc" then "V9 ABI" is what
gets used, the two options are compatible with each other and the "V9
ABI" is the super-set of the two.
The default distributions for Linux support all 3 ABIs modes, when the
CPU is 64bit capable. The kernel is built for 64bit, and has support
for all 3 ABIs so userspace can use any ABI.
The default ABI emitted from GCC with no additional options given is V8
ABI on most linux distros that use 64bit kernel and 32bit default userspace.
Never the less after all this adding DES_INT does make linux64-sparcv9
pass a "make test" check.
Maybe Intel IA32 x86_64 might have an i386plus ABI one day. More
registers and better cdecl calling convention, definite 64bit insn
support but 32bit pointers and 32bit userspace. :)
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
