Re: Linux/Sparc64/64bit ABI + OpenSSL 0.9.8/0.9.8e + GCC 4.1.2: make test failure
Andy Polyakov wrote: DES_LONG *can* be 8 bytes, it's just that it can't be 8 if you want to deploy des_enc-sparc.S module. As mentioned adding DES_INT in stable branch is inappropriate as it may break installations which are opted for 64-bit ABI, but started compiling the toolkit with no-asm. So that we have to disengage assembler module... Unless evidence is presented that SPARC Linux vendors already patch it anyway. A. Okay understood on the reason to keep things as they are. To confirm things back make test works if you remove the des_enc-sparc.o fcrypt_b.o which appears to make it use the generic C implementation. So if that change can be updated into the 0.9.8 tree. Then for the 0.9.9 tree keep the des_enc-sparc.o fcrypt_b.o but also add DES_INT. This is for the target linux64-sparcv9. Just out of interest what distributions are shipping a native 64bit Linux SPARC ? From looking over debian 4.0 that is using 0.9.8 by default is has the v8 (in /lib/v8/) and the v8plus versions (in /lib/v9/) but there is no 64bit v9 versions shipped in the /lib64/ directory. None of the executables shipped with any SPARC distribution I have seen are 64bit, let alone ones that link with OpenSSL. Only a skeleton runtime 64bit support is shipped which just means a handful of DSOs and OpenSSL is not amongst them. Debian 4.0 is the distribution I have installed. These number of active Linux SPARC distributions these days might be down to a tiny handful. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Linux/Sparc64/64bit ABI + OpenSSL 0.9.8/0.9.8e + GCC 4.1.2: make test failure
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 openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Linux/Sparc64/64bit ABI + OpenSSL 0.9.8/0.9.8e + GCC 4.1.2: make test failure
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. I don't think it is a compiler bug, FYI it was GCC 4.1.2 which is pretty recent 20061115. Well, compiler being recent is no guarantee that it's bug-free:-) 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, If sizeof(DES_LONG) is 8, then key schedule and SPtrans are 1KB and 4KB and 1/2 of it would be wasted, because 1/2 will remain unreferenced. More data than necessary will be brought into cache and therefore more data than necessary will be evicted as result of DES call. 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. Aaah! This explains it. All right, it's not compiler bug, as des_enc-sparc.S is coded for sizeof(DES_LONG) of 4, i.e. it expects key schedule to occupy 512 bytes and SPtrans - 2K, yes even in its 64-bit incarnation. To verify try to config with no-asm. DES_LONG *can* be 8 bytes, it's just that it can't be 8 if you want to deploy des_enc-sparc.S module. As mentioned adding DES_INT in stable branch is inappropriate as it may break installations which are opted for 64-bit ABI, but started compiling the toolkit with no-asm. So that we have to disengage assembler module... Unless evidence is presented that SPARC Linux vendors already patch it anyway. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Linux/Sparc64/64bit ABI + OpenSSL 0.9.8/0.9.8e + GCC 4.1.2: make test failure
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. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Linux/Sparc64/64bit ABI + OpenSSL 0.9.8/0.9.8e + GCC 4.1.2: make test failure
The problem was the setting for linux64-sparcv9 within Configure.
Currently in 0.9.8e:
SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_UNROLL
BF_PTR:::des_enc-sparc.o fcrypt_b.o
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.
However there are another 2 options in the solaris64-sparcv9-cc and
solaris64-sparcv9-gcc entries (which are the closest), I have compiled
with these options on solaris for 64bit both with SunPro CC and GCC and
those builds are fine as they are.
These additional settings should probably be added to the
linux64-sparcv9 entry (I have built with these for linux64-sparcv9 w/
GCC and 'make test' was successful) :
DES_INT DES_PTR DES_RISC1
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; so it
makes sense to include this in the testcase.
if(sizeof(DES_LONG) != 4) {
printf(ERROR: sizeof(DES_LONG) != 4: You are probably on a 64bit host
CPU and have not setup the DES_INT build option.\n);
err=1;
}
Darryl
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Linux/Sparc64/64bit ABI + OpenSSL 0.9.8/0.9.8e + GCC 4.1.2: make test failure
Is this a known issue for Linux Sparc when building for 64bit ? 0.9.8e fails, 0.9.8 fails, 0.9.7m pass (with minor s/-march/-mcpu/ fix) ? It seems all version of 0.9.8 series fail the same way ( tried 0.9.8e and 0.9.8). The build itself appears to complete successfully. When building for 32bit ABI the tests complete fine on 0.9.8e. When building for 64bit ABI the tests complete fine on 0.8.7m. $ uname -a Linux hostname 2.6.18-4-sparc64 #1 Tue May 1 22:30:17 UTC 2007 sparc64 GNU/Linux $ gcc -v Using built-in specs. Target: sparc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-cpu=v8 --enable-checking=release sparc-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) $ cat /etc/issue Debian GNU/Linux 4.0 \n \l $ ./Configure linux64-sparcv9 $ make $ make test SNIP... make[3]: Entering directory `/data/BUILD/openssl-0.9.8e/apps' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/data/BUILD/openssl-0.9.8e/apps' make[2]: Leaving directory `/data/BUILD/openssl-0.9.8e' ../util/shlib_wrap.sh ./destest Doing cbcm des_ede3_cbcm_encrypt decrypt error 37 36 35 34 33 32 31 20 4e 6f 77 20 69 73 20 74 68 65 20 74 69 6d 65 20 66 6f 72 20 00 37 36 73 44 33 32 31 20 4a 6f 9d 18 69 73 20 74 63 65 ea a0 69 6d 65 20 6f 6f c1 70 00 Doing ecb Encryption error 1 k= p= o=8CA64DE9C1B123A7 act= Encryption error 2 k= p= o=7359B2163E4EDC58 act= Encryption error 3 k=3000 p=1001 o=958E6E627A05557B act=21006781 Decryption error 3 k=3000 p=21006781 o=1001 act=18002141 ...SNIP... Doing cbc_cksum bad return value (45784664), should be F7FE62B4 bad cbc_cksum block returned Doing quad_cksum input word alignment test 0 1 2 3 output word alignment test 0 1 2 3 fast crypt test make[1]: *** [test_des] Error 1 make[1]: Leaving directory `/data/BUILD/openssl-0.9.8e/test' make: *** [tests] Error 2 $ Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
