This is a discussion on Re: Linux/Sparc64/64bit ABI + OpenSSL 0.9.8/0.9.8e + GCC 4.1.2: make - Openssl ; >>> 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 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 firstname.lastname@example.org
Automated List Manager email@example.com