Is there any reason why gcc -print-prog-name=collect2 is used for
detecting the linker instead of gcc -print-prog-name=ld? As far as I
know collect2 isn't actually used when linking c code. I've come
across a system where gcc -print-prog-name=ld points to the vendor
linker and gcc
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
We're making test on DUnix Tru 64 and we had problem with this library:
make test result:
test BN_sqr
Square test failed!
Our op. sys is: OSF1 link.softax.local V5.1 732 alpha
our compiler is:
Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732)
I failed to reproduce the problem with
No, I get exactly same error:
NIST curve P-521 -- Generator:
x =
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
y =
to facilitate building openssl on the x86_64 platform I suggest to apply
the attached patch.
+linux-x86_64, gcc:-DL_ENDIAN -DNO_ASM:
Linux/x86_64 suports two ABIs. As far as I understand it's perfectly
possible to compile gcc so that it supports both. Which one will be
default? To ensure that
No, I get exactly same error:
NIST curve P-521 -- Generator:
x =
0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66
y =
so, once more. I've tested now openssl-0.9.7-beta4:
./Configure irix-mips3-cc --prefix=/usr/local/openssl
--openssldir=/usr/local/openssl no-threads
Configuring for irix-mips3-cc
IsWindows=0
CC=cc
CFLAG =-DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_KRB5 -n32 -O2
I guess we should put out a call for anyone of a speed-obsessed
inclination to let us know if they notice any overhead problems with
these changes.
Does the code have to be so obscure? Is it recognized that it's
byte-order dependent? Is it intentional?
On little-endians it is
levitte bn_div_words(0xC383,0x838B4B53,0x8000)
Hmm, a call like that gave me an aruthmetic error on Linux...
According to bc 0xC383838B4B53 / 0x8000 = 0x18707. The
result is 33 bits or in other words the operation *overflows*. According
to IA-32 manual overflow is
I just changed ./Configure line:
#linux64-sparcv9,sparc64-linux-gcc:-m64 -mcpu=v9 -DB_ENDIAN -DTERMIO
-O3 -fomit-frame-pointer -Wall
-DBN_DIV2W::-D_REENTRANT:ULTRASPARC::BN_LLONG RC4_CHAR RC4_CHUNK
DES_UNROLL BF_PTRasm/md5-sparcv9.o:,
by
linux64-sparcv9,gcc:-m64 -mcpu=v9
appro linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3
appro -fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG
appro RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:,
Hmm, I assume we can make that change in Configure, eh?
My idea was to
linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3
-fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG
RC4_CHAR RC4_CHUNK DES_UNROLL BF_PTRasm/md5-sparcv9.o:,
all test passed (./Configure linux64-sparcv9 no-asm without no-asm).
Next step is to add
error in make:
oops!
Next step is to add shared lib bits. Therefore change to:
linux64-sparcv9,gcc:-m64 -mcpu=ultrasparc -DB_ENDIAN -DTERMIO -O3
-fomit-frame-pointer -Wall::-D_REENTRANT:ULTRASPARC::SIXTY_FOUR_BIT_LONG
RC4_CHAR RC4_CHUNK DES_UNROLL
Does it build?
+gcc -m64 -shared -o libcrypto.so.0.9.7 -Wl,-soname=libcrypto.so.0.9.7
-Wl,-Bsymbolic -Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive
-L. -lc
libcrypto.a(dso_dlfcn.o)(.text+0x68): In function `dlfcn_load':
: undefined reference to `dlopen'
Double oops:-) Of course
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
Ok. the last line in Configure that I've tested is:
linux64-sparcv9,...
do you want that I test another configuration?
Well, it would be nice if you could verify that linux-sparcv9 and
linux-sparcv8 work...
What is necessary to include this configuration in 0.9.7-snapshots?
Nothing. It
Yes, this patch helps with gcc 3.2.1, and not only the test_rsa passes,
but also the other test that had failed (test_sid).
Does it mean that the *whole* test suite passes? I.e. 'make test'
actually finishes completely and without error? As mentioned NUE-1.2
fails in test/dsatest...
o BN_mod_mul verification fails for mips3-sgi-irix
unless configured with no-asm
Who reported this? I can't reproduce it! A.
__
OpenSSL Project http://www.openssl.org
Development
However, I should note that I read file PROBLEMS
and did not see anything about tru64. Maybe there should be a pointer to
the FAQ?
Well, there is a pointer from ./FAQ to ./PROBLEMS... And to me it
appears like ./PROBLEMS could be merged into the ./FAQ... So I suppose
consensus is not
I have been working on
BN assembler aided implementation that would need some benchmarking. It
should give around 3x speed-up...
Preliminary patch relative to 0.9.6h is available at
http://www.openssl.org/~appro/. Once it's confirmed to be working on
real hardware, it will be ported/merged to
appro I have been working on
appro BN assembler aided implementation that would need some benchmarking. It
appro should give around 3x speed-up...
appro
appro Preliminary patch relative to 0.9.6h is available at
appro http://www.openssl.org/~appro/. Once it's confirmed to be working on
appro Well, *if* this is supposed to be the last beta, then the only question
appro is if we *dare* to merge the code directly into the final version, i.e.
appro without exposing it in beta. I consider that we can dare to do so as
appro long as SuSE Labs promise that they would double-check
This message goes to openssl-dev and not to rt as I'd like to discuss
couple of issues before the code is committed.
And even better news are that it appears to be possible to squeeze out a
register at the cost of [presumably] slight performance degradation on
Pentium II and earlier. So how
Gotten anywhere?
Not yet. Well, I can tell that it's not assembler fault (it fails even
if I compile with no-asm) and it's the same fault with both cc and gcc.
Weird...
Is this part of the things you and I have discussed today?
No. A.
Gotten anywhere?
Not yet. Well, I can tell that it's not assembler fault (it fails even
if I compile with no-asm) and it's the same fault with both cc and gcc.
Weird...
Is this part of the things you and I have discussed today?
No. A.
^^ But it probably should be! A.
appro Should we check for -.pic also?
I haven't seen any compiler with such a flag, yet...
??? What do you mean? All compilers support both -.PIC and -.pic! Or do
you mean that you have interpreted . literally? I ment . as an arbitrary
character in regular expression and is it was depicted in
appro And even more generally how is it with PIC under Windows
appro anyway? Is it an issue?
I've gotten the impression so far that PIC isn't an issue in Windows.
On the second thought I cam to realize that that form of lea instruction
can't be used in PIC... One has to use mov... But then I
appro appro Should we check for -.pic also?
appro
appro I haven't seen any compiler with such a flag, yet...
appro
appro ??? What do you mean? All compilers support both -.PIC and
appro -.pic! Or do you mean that you have interpreted . literally?
Let me rephrase that: I haven't seen a
appro And even more generally how is it with PIC under Windows
appro anyway? Is it an issue?
I've gotten the impression so far that PIC isn't an issue in Windows.
On the second thought I cam to realize that that form of lea instruction
can't be used in PIC... One has to use mov... But
appro So that if nobody can decline the above paragraph, then the only
appro question that is left is if anybody can verify that proposed patch
appro doesn't actually break Windows build. Or should I just let the code
appro appear in a snapshot?
Commit it and let people test snapshots.
appro But back to the originating ticket. Shall we add that -shared flag to
appro gcc command line? What was the consensus?
Uhmm, I thought it already did in 0.9.7? If it doesn't, that's a
fault in Makefile.org. You have to look at the target
do_solaris-shared, and see why
My solution was to add support for assembly modules.
Why do you want to add more rules? Well, I actually fail to understand
why can't we have a unified rule? I mean something like this:
asm/dx86-elf.o: asm/dx86unix.cpp
$(CPP) -DELF asm/sx86unix.cpp | \
sed -e 's/\. /./g'
The crucial thing to test is that things are still working properly in
Windows, especially the DES assembler modules. They been changed to
generate PIC code on Unix, and it's important that we get tests on how
that affects Windows, if it does.
Try openssl-0.9.7-SNAP-20021214 instead as it
Richard Levitte - VMS Whacker wrote:
In message [EMAIL PROTECTED] on Sat, 14 Dec
2002 23:41:00 -0800 (PST), Doug Kaufman [EMAIL PROTECTED] said:
dkaufman gcc -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_SYSNAME_CYGWIN32
-DOPENSSL_THREADS -DDSO_WIN32 -DOPENSSL_NO_KRB5
dkaufman ../libcrypto.a(dx86-out.o)(.text+0x68):des-586.s: undefined reference to
`DES_SPtrans'
dkaufman ../libcrypto.a(dx86-out.o)(.text+0xf3a):des-586.s: undefined reference
to `DES_SPtrans'
dkaufman ../libcrypto.a(yx86-out.o)(.text+0x9):crypt586.s: undefined reference to
`DES_SPtrans'
Whoaa there, how does that change work when the compiler is *not* GNU?
It works *perfectly* with vendor compiler! Trust me:-) A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
appro Whoaa there, how does that change work when the compiler is *not* GNU?
appro
appro It works *perfectly* with vendor compiler! Trust me:-) A.
Really? They understand -Wl?
Yes. Well, I can tell for version 3, but even WorkShop C 4 understands
-Wl. There is a whole bunch of compiler
appro Whoaa there, how does that change work when the compiler is *not* GNU?
appro
appro It works *perfectly* with vendor compiler! Trust me:-) A.
Really? They understand -Wl?
Yes. Well, I can tell for version 3,
^^^ I meant I can *not* tell for for version 3. A.
appro Whoaa there, how does that change work when the compiler is *not* GNU?
appro
appro It works *perfectly* with vendor compiler! Trust me:-) A.
Really? They understand -Wl?
Yes.
Richard, you win but for another reason:-) WorkShop C (as well as other
vendor compiler drivers) does
appro Richard, you win but for another reason:-) WorkShop C (as well as other
appro vendor compiler drivers) does understand -Wl, *but* some of thier
appro (Sun's) compiler drivers (well, one of those I have) collect all -Wl
appro options in the beginning of ld command line so that ld is
Please please please forget about that allextract nonsense. You will*never*
get it portable to all desired platforms.
The changes being discussed affect Solaris and Solaris only, we're not
talking about all desired platforms.
Just take the lib*.a and relink it
explicitly:
mkdir tmp;
Rich.PurvisI have looked through the email posts and seen the
Rich.Purvis patch submitted by John Calcote and the discussion that
Rich.Purvis followed, concerning the fact that it doesn't fully
Rich.Purvis account as a full port for Win64. I did see that there
Rich.Purvis was a Win64
appro 'a=b c=$a; echo $c' doesn't necessarily prints b,
I don't understand the first part of that log,
Under bash:
$ a=b c=$a; echo $c
b
While under Solaris /bin/sh:
$ a=b c=$a; echo $c
i.e. it prints nothing. You need a=b; c=$a; echo $c to see b. A.
levitte
levitte appro Under bash:
levitte appro
levitte appro $ a=b c=$a; echo $c
levitte appro b
levitte appro
levitte appro While under Solaris /bin/sh:
levitte appro
levitte appro $ a=b c=$a; echo $c
levitte appro
levitte appro i.e. it prints nothing. You need a=b; c=$a; echo $c to
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
??? At RT page I
I have to recommend to always mention which platform is affected.
Well, normally I would but I figured that as the bug could be reproduced
with a portable perl command would affect any a.out target that the
platform was irrelevant...
It is relevant as I was unaware of any target that
The fix is committed to cvs repository. If you don't feel like pulling
down the cvs tree, apply attached patch, rm crypto/des/asm/*.o and rerun
make.
The procedure for fetching the patch is
- go to http://www.aet.tu-cottbus.de/rt2/
- login as guest:guest
- goto ticket 405;
- click on download
Hi,
I've put together an OpenSSL 0.9.6h package using GNU autoconf, available
from:
http://site.rpi-acm.org/info/openssl/
This is surely great, but I find it unfair/inappropriate that no
information whatsoever is provided on
- how does the content of this package differs from the
My solution was to add support for assembly modules.
We probably have to postpone this patch to 0.9.7a. If you only could
reply more swiftly so that the changes could be exposed in beta...
Most improtantly
I don't think so! It must be complaining about leal
appro I can imagine / :/:/, but where do /\. /./ and /@ /@/ some from? Can you
appro pinpoint the lines? I mean just give the offending lines' number...
Actually, I have no problem seeing that spaces might be added at least
around '.' by $(CPP). Some modern C preprocessors do separate
Danm!
Double damn! I can't spell damn! Well, it's not like it's appropriate
time for that kind of language:-) A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
tim I've attached a couple of sed man pages. (in case you figure it out first)
Hmm, they both refer to ed for regular expressions...
They used to have manual pages on-line, but apparently it's moved...
Aha! See http://www.caldera.com/support/docs/. No need to bore the whole
list with
appro maybe we should be using perl.
appro
appro If it ought to be perl, then I'd rather get rid of $(CPP) altogether. In
appro which case I'd implement elf-pic perlasm option and simply
appro
appro asm/dx586-elf.o: asm/dx586-elf.s
appro $(CC) $(CFLAGS) -o $@ $
appro
appro
appro appro and make sure perl emits universal code (i.e. no comments:-). Note
that
appro appro the first rule automatically covers for -b elf of yours:-)
appro
appro How about reworking that for 0.9.8? Or if you dare, for 0.9.7a?
appro
appro ??? I already said that I'm holding this
appro Yet I'd dare:-) If it was up to me and if Tim is with us [i.e. is ready
appro to swiftly verify a snapshot on explicit request], I'd pull it [unified
appro *586-elf.o rules] even now:-) I have Linux and Solaris/Intel,
appro login.openssl.org is a FreeBSD machine... So shall we?
I
tim sco5-gcc FAILS (removing ${x86_elf_asm} should fix this)
tim I don't think anyone tries to put gnu ld on
tim SCO OpenServer 5.
In any case, as far as I see we have two choices for 0.9.7:
1. insert the proposed perl filter (it works as stated, and I feel
3. Remove ${x86_elf_asm} from sco5-gcc line.
This should be done even without any other changes.
You'll notice that ${x86_elf_asm} was added to the sco5-gcc line
for 0.9.7 and it never worked.
^^^ I see...
4. Replace ${x86_elf_asm} in sco5-gcc rule with
3. Remove ${x86_elf_asm} from sco5-gcc line.
Feels like a wrap-up point for me... I've verified
solaris[64]-sparcv9-[g]cc, solaris-x86-gcc, irix[64]-mips3-cc,
linux-alpha-[gc]cc, linux-x86_64 and linux-ia64(*) targets. Well, not to
mention linux-pentium and FreeBSD-elf...
As for DES assembler
VMWare - OpenBSD 3.2 , gcc 2.95.3
Got error when compiling 0.9.7 beta 6:
--
gcc -E -DOUT asm/dx86unix.cpp | as -o asm/dx86-out.o
des-586.s: Assembler messages:
des-586.s:2458: Error: Unimplemented segment type 135296 in
It looks like the PIC changes to crypto/perlasm/x86unix.pl break
on non gcc compilers.
First of all it's an assembler issue, not compiler. And I don't think
it's GNU vs. vendor assembler issue, ...
UX:acomp: ERROR: asm/dx86unix.cpp, line 122: invalid input token: 1f
UX:acomp: ERROR:
Ok. the last line in Configure that I've tested is:
linux64-sparcv9,...
do you want that I test another configuration?
I wonder if you could spare some time and test linux-sparcv9 in
ftp://ftp.openssl.org/snapshot/openssl-SNAP-20030103.tar.gz or later.
There is DES assembler implementation
The cc on UnixWare 2.x doesn't handle -o asm/xx86-elf.o
It just creates it in the curent directory.
??? Does it mean that cc driver effectively ignores -o option? Or does
it mean that make doesn't pass -o option to cc driver when compiling .s
files? If former, does it apply to .s files only?
The cc on UnixWare 2.x doesn't handle -o asm/xx86-elf.o
It just creates it in the curent directory.
??? Does it mean that cc driver effectively ignores -o option? Or does
it mean that make doesn't pass -o option to cc driver when compiling .s
files? If former, does it apply to .s
Options:
1. Move *-elf.[os] one level up, e.g.:
dx86-elf.s: asm/des-586.pl ../perlasm/x86asm.pl ../perlasm/cbc.pl
(cd asm; $(PERL) des-586.pl elf $(CFLAGS) ../dx86-elf.s)
This option didn't work out very well.
...
making all in crypto/md5...
cc -c
Try out openssl-SNAP-20030109 as it becomes available or 'cvs checkout'.
UnixWare 2.x and SCO3 remain without assembler support. If you feel
emotionally attached to these two, I'd suggest to trade assembler
support for a comment in ./Configure which says that
[EMAIL PROTECTED] is the one to talk
I've checked in a fix for that and another isssue which should fix things.
if (keyfree key)
??? Bitwise and??? Don't you mean (keyfree key)? A.
__
OpenSSL Project http://www.openssl.org
However, currently I'm unfortunately unable to release a Cygwin net
version of 0.9.7 due to a linker problem, which results in dropped
symbols in the link stub library. The most prominent dropped symbol
is RC4. Building OpenSSH with this libs results in ssh and sshd crashing
immediately
What I don't understand is the following.
crypto/rc4/Makefile.ssl contains the following:
RC4_ENC=rc4_enc.o
# or use
#RC4_ENC=asm/rx86-elf.o
#RC4_ENC=asm/rx86-out.o
#RC4_ENC=asm/rx86-sol.o
#RC4_ENC=asm/rx86bdsi.o
Even though it's supposed to build rc4_enc.o to get the
As for .*_end symbols. Apparently there're more... Any particular reason
why are you complaining just about .RC4_end?
No. Just the one I found first due to the ssh crash.
Until I found a solution for that linker problem (which is a linker bug,
apparently) I'd like to build the
Until I found a solution for that linker problem (which is a linker bug,
apparently) I'd like to build the Cygwin version using rc4_enc.o. How
can I do that most cleanly?
By fixing rx86-out.o:-) A.
Did it ever work? Assembler support in cygwin-shared build that is? BN
stuff
Until I found a solution for that linker problem (which is a linker bug,
apparently) I'd like to build the Cygwin version using rc4_enc.o. How
can I do that most cleanly?
By fixing rx86-out.o:-) A.
Did it ever work? Assembler support in cygwin-shared build that is? BN
And I don't think it's openssl's fault.
Yes, it apparently is... Compile foo(){} with cc -S and note that
compiler add some .def ... .endef line, but not perlasm thing which is
reponsible for assembler code generation.
I'm going
to ask some linker experts...
Ask about this .def ... .endef
And I don't think it's openssl's fault.
Yes, it apparently is...
Verify that the attached patch solves the problem.
I'm going
to ask some linker experts...
Ask about this .def ... .endef line. Any documentation available
on-line?
I found the documentation for .def ... .endef, but
--
OpenSSL Shared Libraries have been installed in:
[directory name]
If this directory is not in a standard system path for dynamic/shared
libraries, then you will have problems linking and executing
applications that
Unfortunately, about -R/-rpath, I've avoided it so far for exactly the
reason you mentioned: it doesn't quite support moving libraries to a
dofferent place and still have it work.
And that is what I'm suggesting to adhere to. I.e. to avoid it (and even
to remove it from tru64!) and leave this
dkaufman I noticed that the makefile contains a special line for
dkaufman DJGPP, similar to the one for Cygwin. This isn't needed for
dkaufman DJGPP. Patch attached.
Please explain why .dll loading would be different in that particular
case...
Because loading of Windows .dll is not an
This is a preliminary patch and I need to think it through before I
commit it. Maybe we should solve it in some other way (like with ELF).
Any DJGPP out there who care to verify if this doesn't break DJGPP?
I tried this patch on DJGPP both as normally compiled and also using
the asm
I tried this patch on DJGPP both as normally compiled and also using
the asm modules (put ${x86_out_asm} in the DJGPP config-string
^^^ Oh! I missed that. I mean the fact that they are not
actually engaged in the default configuration. Any particular reason
why?
The
When i am making the openssl-0.9.7 with cc under SCO UNIX5.0.5,the
prompt of wrong message is that fatal error: library not found: -lresolv
*** Error code 1 (bu21)
*** Error code 1 (bu21)
How can i do? I am very glad to get
.
Thank you very much for your attention,
Vladimir
-Original Message-
From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 4:27 PM
To: Shklover, Vladimir
Cc: [EMAIL PROTECTED]
Subject: Re: [openssl.org #463] PATCH
Current version,
openssl-0.9.7
To summarize. I'm hardcoding i586 to all Caldera/SCO targets. And
according to RT#460 we also should get rid of -lresolv on those
platforms, right? A.
And yes, get rid of -lresolv on the sco5 (OpenServer 5) targets.
The question also is if it's needed even in unixware-2.* lines. As
. This didn't crash the program on
solaris and linux. But maybe that's too much for the first time.
Vladimir
-Original Message-
From: Andy Polyakov via RT [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 20, 2003 2:25 PM
To: Shklover, Vladimir
Cc: [EMAIL PROTECTED]
Subject: Re
to make things clear, how to check if a Win32 exe is currently running
as a NT service:
1.) Check if the SID (security ID) of the current process is S-1-5-18,
i.e. the so called LOCALSYSTEM account. This changes if you configure
your service (in the services control panel) to run on a
There is more reliable way. For example.
h = GetProcessWindowStation();
if (h==NULL) fatal error; /* or return runs as service */
if (GetUserObjectInformationW (h,UOI_NAME,NULL,0,NULL,len) ||
GetLastError() != ERROR_INSUFFICIENT_BUFFER)
fatal error; /* or return runs as service
Is there interest in making the library "const correct"?
Yes.
I have some SSLeay-0.9.0b stuff left. Andy.
*** ./crypto/asn1/asn1.h.orig Thu Apr 9 14:11:07 1998
--- ./crypto/asn1/asn1.hThu Jul 16 18:59:18 1998
***
*** 242,248
char *sn,*ln;
int nid;
(--num == 0) break;
mul_add(rp[3],ap[3],w,c1);
if (--num == 0) break;
ap+=4;
rp+=4;
}
Cheers. Andy.
.ident "bn_asm.sparc.v8plus.S, Version 1.0"
.ident "SPARC v9 ISA artwork by Andy Polyakov [EMAIL PROTECTED]"
/*
* =
O.K. Then I propose deleting (rather then recreating) all those
automatically generated assembler versions, with appropriate changes
to the configuration script.
i don't get it! has anybody read my posts? does it get through at all?
well, it must, because i myself get my messages
Hi again!
And finally.
I slept over it and want you to disregard the following statement of
mine:
... It (*) doesn't make any difference to my UltraSPARC-specific
implementation (as I exploit branches on register condition with
prediction) ...
(*) unrolling loops in below way
because
Hi! Following is far from what I'd consider as a good programming
practice... First a trivial table everybody would recognize:
Intel,SPARCv8,MIPS 32 Alpha,SPARCv9,MIPS 64
sizeof(int) 4 4
sizeof(long)4 8
performance has dropped by a factor of 2.5 ... 4!!!
Did you use the same compiler flags for both builds?
Yes, of course!
but on which platform? which compiler? a.
__
OpenSSL Project
. If there actually *are* UltraLinux people out
there *really* interested in this, contact me and we'll see...
Cheers. Andy.
.ident "bn_asm.sparc.v8plus.S, Version 1.2"
.ident "SPARC v8plus ISA artwork by Andy Polyakov [
Hello again!
I wrote:
#elif defined(BF_PTR)
/* This is normally very good */
#define BF_ENC(LL,R,S,P) \
LL^=P; \
LL^= (((*(BF_LONG *)((unsigned char *)(S[ 0])+((RBF_0)BF_M))+ \
*(BF_LONG *)((unsigned char *)(S[256])+((RBF_1)BF_M)))^ \
Hi! For those who dare:-) With all my "LP64 woes" patches applied
drop following into Configure and experience the power of 64 bits
computing with UltraSPARC.
"solaris64-usparc-cc","cc:-xtarget=ultra -xarch=v9 -Xa -xO5 -xdepend -xstrconst
-DB_ENDIAN:\
-lsocket -lnsl:\
#if !defined(BF_PTR) !defined(BF_PTR2)
#define BF_PTR
#endif
i.e. the comment is effectively *disregarded*, isn't it?
This is autogenerated in Configure.
Oops! I suppose I owe an apology for my comment following the quoted
string then. I apologize and I'm sorry!
BUT! Even after
On the other hand! Does the library actually *compile* under
MS-DOS/WIN16? Does *anybody* actually use it?
I think Steve still builds Win16 versions.
No I don't. Win16 is too painful but when dropping support was mentioned
a while ago someone mentioned various applications that used
Hi! I do realize that I'm concentrating on wrong matters (after all,
blowfish is never used by SSL applications), but I couldn't abstain from
commenting:-) First of I fail to understand why #define BF_PTR2 would
perform better than the last "generic" version. The one that performs
best on Alpha:
crypto/opensslconf.h.in by Ulf). I don't see any need for it, so I've
folded the whole mumbo-jumbo to #undef BF_PTR:-)
If BF_PTR should normally not be defined, we can simply remove it
from opensslconf.h and the Configure script. Is that what you mean?
NO! That's defintely *NOT* what I
Failure:
===
IRIX 6.5.3m [2]
[2] bignum code is broken.
I get through bntest and rsa_oaep_test, but not through exptest.
BN_mod_exp_recp is the one that breaks... Andy.
__
OpenSSL Project
Hello, guys!
The other angle that comes to mind is if there are machines where "unsigned
int" is 64 bits. Seems like Cray's are that way.
Will the code still work on such a machine?
Find attached patch relative to openssl-SNAP-19990421 snapshot. This is
my "final" proposal:-) Well, I call
Just looked at latest Configure file...
I was just about to suggest to rename solaris-sparc-cc to
solaris-sparc-sc3 and solaris-*-sc4 to solaris-*-cc which would cover
both SC4.x and SC5.x... But I can see you've introduced sc5 option:-(
In either case I don't find my v8plus implementation of
1 - 100 of 1949 matches
Mail list logo
