> the test 'trsa' in the testsuite fails on ia64:
>
> testing rsa conversions
> p -> d
> p -> p
> d -> d
> make[1]: *** [test_rsa] Error 1
> make[1]: Leaving directory
> `/usr/src/packages/BUILD/openssl-0.9.7_beta4/test'
> make: *** [tests] Error 2
I managed to reproduce the problem under nue (IA-64 emulator for Linux)
and with gcc 2.96 (the one found in nue-fs-1.2-1). It's a compiler bug:
*** ./crypto/asn1/a_d2i_fp.c.orig Sun Nov 24 18:14:40 2002
--- ./crypto/asn1/a_d2i_fp.c Sun Nov 24 18:15:16 2002
***************
*** 149,155 ****
ASN1_CTX c;
int want=HEADER_SIZE;
int eos=0;
! int off=0;
int len=0;
b=BUF_MEM_new();
--- 149,155 ----
ASN1_CTX c;
int want=HEADER_SIZE;
int eos=0;
! size_t off=0;
int len=0;
b=BUF_MEM_new();
Does this help gcc 3.2.1? This patch takes me to the next failing test,
test/dsatest to be specific, which surely also caused by another
compiler bug[which I didn't track down yet].
I also tested ecc 5.0.1 (Intel compiler). That one required following
patch:
*** ./crypto/aes/aes_cbc.c.orig Sat Nov 23 00:16:50 2002
--- ./crypto/aes/aes_cbc.c Sun Nov 24 14:54:31 2002
***************
*** 64,70 ****
unsigned char *ivec, const int enc) {
unsigned long n;
! unsigned long len = length;
unsigned char tmp[AES_BLOCK_SIZE];
assert(in && out && key && ivec);
--- 64,70 ----
unsigned char *ivec, const int enc) {
unsigned long n;
! long len = length;
unsigned char tmp[AES_BLOCK_SIZE];
assert(in && out && key && ivec);
*** ./crypto/bn/bn_lcl.h.orig Tue Mar 26 00:14:50 2002
--- ./crypto/bn/bn_lcl.h Fri Nov 22 21:59:01 2002
***************
*** 337,347 ****
#define LBITS(a) ((a)&BN_MASK2l)
#define HBITS(a) (((a)>>BN_BITS4)&BN_MASK2l)
! #define L2HBITS(a) ((BN_ULONG)((a)&BN_MASK2l)<<BN_BITS4)
#define LLBITS(a) ((a)&BN_MASKl)
#define LHBITS(a) (((a)>>BN_BITS2)&BN_MASKl)
#define LL2HBITS(a) ((BN_ULLONG)((a)&BN_MASKl)<<BN_BITS2)
#define mul64(l,h,bl,bh) \
{ \
--- 337,346 ----
#define LBITS(a) ((a)&BN_MASK2l)
#define HBITS(a) (((a)>>BN_BITS4)&BN_MASK2l)
! #define L2HBITS(a) (((a)<<BN_BITS4)&BN_MASK2)
#define LLBITS(a) ((a)&BN_MASKl)
#define LHBITS(a) (((a)>>BN_BITS2)&BN_MASKl)
#define mul64(l,h,bl,bh) \
{ \
Yepp, it's a mess... I've never tested ecc 6.0.1. Unlike 5.0.1, that one
is native IA-64 binary code and therefore are way too slow to run in
simulated environment. Do you have real IA-64 hardware? Preferably
Itanium 2 as the assembler module needs tuning just for it. If answer is
yes, is it possible to arrange an account?
Some general IA-64 ABI notes if anybody cares/is interested. As usual
'I' stands for integer, 'L' for long and 'P' for pointer. If not
explicitely mentioned, size is assumed to be 32 bits. In other words
LP64 means sizeof(int)==4, sizeof(long)==8, sizeof(void*)==8.
Linux supports LP64 ABI only.
HP/UX supports both LP64 and ILP32 ABIs. LP64 is the only one currently
supported/recognized by OpenSSL (on HP/UX/IA-64 that is). If anybody is
interested in ILP32 support, contact <[EMAIL PROTECTED]> and get
prepared to answer zillions of small questions.
Win64 in turn implements P64 ABI with *run-time* option for P32.
"Run-time option for P32" means that compiler itself is basically not
aware of this, i.e. generates the code without regard to this. P32 is
engaged at run-time basically through limiting virtual address space to
2GB. You can choose it by linking with /LARGEADDRESSAWARE:NO or
modifying the existing binary with EDITBIN /LAGEADDRESSAWARE:NO. Idea
with P32 is to provide working environment for legacy apps which freely
cast pointers to integer and vice versa. But note this never applies to
handlers to kernel objects as some earlier post on the list implied. I
mean it's perfectly possible to cast handlers to kernel objects to
integers and vice versa even though they are declared as void * even in
P64! Simply because handlers to kernel objects are not pointers, but
indexes in per-process table. Of course problem is that in such large
and diverse API it's very easy to loose the track which interfaces
return handler to kernel object and which ones - real pointers to
user-land objects.
A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
