But the main question was about how context switch is handled between
save and say mulmont. I mean the part after save-s ought to allocate
frames.
I'm confused.
The cpu has 8 register windows.
This means that we can save down 7 times and fill all of the
registers in each window with the
About the RAS stack missing cost, every Sun produced UltraSPARC chip
pushes unconditionally onto the RAS and does not special case the
call.+8
pattern.
Thinking about this logically, a RAS miss can (at best) perform like a
full branch misprediction. Which on UltraSPARC results in
I agree that it's not the most optimal, but at the same time no real
reason to fill bad about it.
But on the other hand I've done all the work to implement the macros
to do the PIC sequence properly. You really don't have to implement
anything.
BTW, two other points need restating:
1) My
You mentioned Montgomery BN.
Here are how the instructions work.
The basic model is that there is a range of sizes supported by the
instruction, and all of the data is loaded into a combination of
the floating point registers and all of the register windows of
the cpu.
Ouch!
...
Provide these so that the assembler users can be oblivious about
whether this is PIC or non-PIC, 64-bit or 32-bit, etc.
It is important to use a real call and return to implement the
obtaining of the %pc as part of the PIC sequence. Sequences
such as:
call. + 8
mov
There is no need to send me personal copy.
This is the first phase of changes to support the new cryptographic
opcodes found starting in the SPARC-T4 processor.
Cool.
Oracle provided me with programmer's manuals that document these
instructions, and I've been promised that these would be
I've been porting openssl to run on winrt(metro).
What does it mean more specifically? Even though some assert that WinRT
is totally independent framework directly on top of NT Kernel Services,
it doesn't seem to hold true. The only things that prevents WinRT
programmer from calling any
You can build and link using banned API's , but when you run the app
certification kit , it will give you a fail, and list of all the
function calls you making that you can't make. If you use the .dll's ,
its even worse because it fail you for functions that your not using
but because that
I've been porting openssl to run on winrt(metro).
What does it mean more specifically? Even though some assert that WinRT
is totally independent framework directly on top of NT Kernel Services,
it doesn't seem to hold true. The only things that prevents WinRT
programmer from calling any
For example, you *can* call MessageBox from Metro application if
you declare it yourself and explicitly link with user32.lib. It makes
lesser sense to do so, because you have to switch to desktop in order to
interact with dialog, but it *is* possible.
Just to clarify. I'm not suggesting to
There is more code committed. Check-out or wait for *tomorrow*
openssl-SNAP-20120919 snapshot. There is SmartMIPS AES code (pass
-msmartmips to Configure) and Configure accepts double dash as compiler
options. Please double-check and optionally post performance for new AES
code.
There is more code committed. Check-out or wait for *tomorrow*
openssl-SNAP-20120919 snapshot. There is SmartMIPS AES code (pass
-msmartmips to Configure) and Configure accepts double dash as compiler
options. Please double-check and optionally post performance for new AES
code.
Do I also
Brad House wrote:
There is more code committed. Check-out or wait for *tomorrow*
openssl-SNAP-20120919 snapshot. There is SmartMIPS AES code (pass
-msmartmips to Configure) and Configure accepts double dash as compiler
options. Please double-check and optionally post performance for new AES
./openssl-generic32 speed rsa1024 rsa2048
rsa 1024 bits 0.342000s 0.010615s 2.9 94.2
rsa 2048 bits 1.328750s 0.027632s 0.8 36.2
./openssl-mips32r2 speed rsa1024 rsa2048
rsa 1024 bits 0.128228s 0.008619s 7.8116.0
rsa 2048 bits 1.055000s 0.023870s 0.9 41.9
As
SSL negotiation (where the device is the server) takes about 2s
as it currently stands, and that's with the current MIPS assembler
support in OpenSSL.
I grabbed openssl-SNAP-20120917
...
./openssl-generic32 speed aes-128-cbc sha rsa1024
type 16 bytes 64 bytes256 bytes 1024
I was expecting a bit better performance (in absolute
terms),
Could you double-check one thing? Run 'mipsel-linux-objdump -d
crypto/sha/sha1-mips.o | grep ror | wc'. Do you get a lot of hits? This
is to double-check that -mips32r2 was in fact effective and passed down
_MIPS_ARCH_MIPS32R2
The str member of EVP_AES_CCM_CTX structure stays uninitialized when aes
ccm is used with the vpaes backend causing it to crash when the str is
later called as it is non-NULL. The attached patch fixes the problem.
http://cvs.openssl.org/chngview?cn=22820. thanks!
It won't accept:
cmp CONSTANT, REG
It will only allow these two forms:
cmp REG, CONSTANT
cmp REG, REG
This is with binutils-2.22 under Linux.
http://cvs.openssl.org/chngview?cn=22821. thanks! for reference,
alternative could have been cmp %g0,$tmp31, in
Brad,
This patchset is against OpenSSL 1.0.1c.
Whatever we will do, will apply to HEAD and optionally 1.0.2. 1.0.1 is
closed for new features, including new platforms, and linux-generic32 is
the one that serves MIPS there.
It does 2 things very minor things.
First, it adds a
What's your target more specifically? You mention 4ksd in commentary,
is it it?
This is the processor I'm running, it is a 32bit 96MHz MIPS 4ksd processor:
http://www.maximintegrated.com/datasheet/index.mvp/id/6134
It looks like n32 is for 64bit CPUs only, so I'm assuming I'm using o32.
Current mips systems have a variety of pipelines:
single-issue in-order, dual-issue in-order, and multi-issue with
dynamic scheduling. Code tuned this way for the R5000 is still
pretty good for all.
Well, dual-issue in-order is the one that can benefit. It's not unlike
that it can sustain
typedef unsigned int uint128_t __attribute__((mode(TI)));
There is builtin __uint128_t type recognized by gcc [reportedly] since
3.1, so that why does one have to clobber it with typedef? Could you
generate assembler listing for following snippet?
unsigned long long foo(unsigned long long
typedef unsigned int uint128_t __attribute__((mode(TI)));
There is builtin __uint128_t type recognized by gcc [reportedly] since
3.1, so that why does one have to clobber it with typedef? Could you
generate assembler listing for following snippet?
unsigned long long foo(unsigned long long
Hi,
1) Firstly, I was surprised about current AES implementation timings. I
wrote the simplest test, containing calls to 4 core AES functions (
AES_set_encrypt_key, AES_encrypt(), AES_set_decrypt_key(), AES_decrypt)
and measured the clocks of some OpenSSL implementations.
This was discussed
Duane,
On related matter. The modules were originally developed on IRIX and
IRIX assembler has very nice feature: it's optimizing code depending on
command line options. This allowed to maintain assembly modules more
readable and let assembler rearrange instruction for optimal
performance.
Using openssl-1.0.1c, cross-compiling for x86 netbsd target.
When libcrypto.so is linked up, I get warnings due to the
OPENSSL_cpuid_setup call in x86cpuid.S:
../lib/gcc/i386--netbsdelf/4.1.3/../../../../i386--netbsdelf/bin/ld: warning:
dynamic relocation in readonly section
In recent RT#2863 regarding aes-mips.pl I found reference to
sha1_armv4_large.patch in Android tree. I find it unfortunate that
problem wasn't reported and I had to find out about it this way. Because
the problem is formally more serious than originally thought. Latter
refers to fact that
I tried building the latest 1.0.1c source tree under win-x64 today, and
there is a problem when using cygwin's perl. It looks like whoever
built the perl scripts for the win-x64 platform made assumptions about
the way perl handles file paths with windows-style backslashes \ in
them.
Bug report in 1.0.1 openssl
In the Mips build of openssl 1.0.1, the Mips assembler module
aes-mips does not define the entry point symbols
private_AES_encrypt_key and private_AES_descrypt_key, and instead
defines duplicate entry points for AES_encrypt_key and AES_decrypt
key.
The fix for this in Android aosp's copy of openssl is file
crypto/aes/asm/aes-mips.pl
of change 40195,
https://android-review.googlesource.com/#/c/40195/3/crypto/aes/asm/aes-mips.pl
Page in question contains a number of patches to .s files. They are not
necessary if you pass o32 to perl
... This
inconsistency deserves a fix, i.e. assigning a default value to
$flavour. Provided if-logic o32 is most appropriate candidate...
Therefore http://cvs.openssl.org/chngview?cn=22765.
For reference, the modification is back-ported to 1.0.2, but not 1.0.1.
This is because 1.0.1 is
$ cvs diff -u -r1.304 -r1.305 TABLE
--- openssl/TABLE18 Apr 2012 13:01:32 -1.304
+++ openssl/TABLE13 Aug 2012 16:10:08 -1.305
@@ -1718,7 +1718,7 @@
*** debug-ben-debug
$cc = gcc
-$cflags = -Wall -pedantic -DPEDANTIC -Wno-long-long
This patch fixes a problem with compiling on Windows for options
OPENSSL_USE_IPV6 and a windows requirement of having _WIN32_WINNT
being at least 0x0501.
It's counterproductive to not specify what is the problem in more
specific terms, naming at least specific error message, OpenSSL version,
when running my application under valgrind, i get a bazillion of
different reports of this type:
...
==9583== Uninitialised value was created by a stack allocation
==9583==at 0x54AD3F7: aesni_cbc_encrypt (aesni-x86_64.s:2081)
reading the code reveals that this is right after a
Not a definitive answer, but I know we (IBM) never tested the PPC asm
on BSD.
It's possible that because no one had a PPC machine running BSD to test
the asm paths they were left disabled.
Correct, the reason for why there is no BSD-ppc is that because there
was no opportunity to test it.
In the file openssl/engines/ccgost/gosthash.c, the function
circle_xor8() is sometimes called with overlapping buffers
(specifically, the *same* buffer), yet uses the memcpy() function
instead of memmove(), which can result in undefined behavior. This
caused a definite problem in some
Do you see any problems with the proposed patch, which could still be
applied to the 1.0.1 trunk to avoid the work-around for non-FIPS users?
As ctx-mres and ctx-ares can't be both non-zero, it's sufficient to
check for (ctx-mres || ctx-ares). Zeroing ctx-ares is not necessary,
because
I think you can indeed remove ar rs completely for 64-bit sparc
too... In a 10 year timeframe some things may have changed... It is
really impressive that you found something in your archive that
happened so long ago. If you put Solaris 10 as minimum OS version,
then you can safely remove
In the file openssl/engines/ccgost/gosthash.c, the function
circle_xor8() is sometimes called with overlapping buffers
(specifically, the *same* buffer), yet uses the memcpy() function
instead of memmove(), which can result in undefined behavior. This
caused a definite problem in some
I am seeing a core dump in RSA_check_key() function. The backtrace
is
as below.
What OS? Which OpenSSL version? Is it correct assumption that it's
custom/own program? Can you reproduce the problem with openssl utility,
with 'openssl rsa -in file.pem -check -noout')? Can you reproduce it
... it's however a little bit faster.
It means the optimization still exist, and I think there should be more
gain if this code is used in OpenSSL SSSE3 codepath (I use completely
different SSSE3 code generation that is possibly less effective).
Not necessarily. Out-of-order execution logic
I've been getting undefined instruction errors in my syslog caused by
the cpu features detection code
in armcap.c. These messages show up when CONFIG_DEBUG_USER is enabled
in the kernel.
Kernel source reads that you also have to initialize specific bit in a
variable. I assume through command
intel-accel-1.5 featuring accumulated bug and portability fixes is
uploaded to http://www.openssl.org/contrib/
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Are there some other required changes missing from the tls-aead-0.9.8.diff
file?
Obviously. Would *md = EVP_md_null() instead of NULL in
ssl_cipher_get_evp() do the trick...
Using EVP_md_null() prevents the seg. fault. However, now the code
generates a Bad Record MAC alert when a client
I used a slightly modified script:
if (@ARGV[0]) {
while() { print foo.$_; }
} else {
print Running on $^O, using: $^X, version $]\n;
open STDOUT,| \$^X\ $0 -;
print bar\n;
close STDOUT;
}
Results (the first sentence is comments of me regarding
When building OpenSSL, using the solaris64-sparcv9-cc config, then
RANLIB uses ar -rs as RANLIB command. Solaris 10 on UltraSparc (in my
case a V440 system) suffers from a bug in:
/usr/ccs/bin/ar:
SunOS 5.10 Generic 144500-19 Jul 2011
The sparc64-sparcv9-cc config seems to
both the FIPS module and OpenSSL use the -pthreads option for gcc when
building a *BSD/x86 target. With our cross-compiler, -pthreads results
in -lpthread, although on our target we actually use libc_r for thread
support. While sorting out how I can resolve this in the
config/Configure
For legacy and compatibility reasons I have to use an older version of the
Windows DDK to compile certain libraries, including OpenSSL. I am
compiling it with version 3790.1830.
In other words compiler version 13.x.
I spent the morning tracing a crash in BN_nist_mod_384 which I believe is
I have couple of questions like,
1.What is FIPS standard OpenSSL 1.0.1 library following. CHANGES claims
the support for FIPS180-2?
What is the concern? That post-FIPS180-2 is not supported? Well, if you
can point out essential difference in specification for algorithms in
question in
You make it sound like the fact that c_d is a stack array is an excuse
for doing wrong:-) I mean it's clearly a compiler bug and reasoning as
above does not make it understandable/justifiable/excusable. Formally
it's not OpenSSL bug and shouldn't be reported as one...
I thought I'd made
I am seeing a core dump in RSA_check_key() function. The backtrace is
as below.
What OS? Which OpenSSL version? Is it correct assumption that it's
custom/own program? Can you reproduce the problem with openssl utility,
with 'openssl rsa -in file.pem -check -noout')? Can you reproduce it
with
http://www.openssl.org/contrib/intel-accel-1.4.tar.gz
I'm attempting to use the libintel-accel-1.4 ENGINE with my OpenSSL
0.9.8x application.
I'm running into a few snags:
1) Why does the sha1_md structure in e_intel_accel.c (L268) set the
required_pkey_type to EVP_PKEY_NULL_method?
I noticed that the Microsoft Assembler compiler support has gone,
however, I also found that ms\do_ms.bat does NOT use assembly (no-asm
flag is used), while ms\do_win64a.bat silently expects nasm compiler
No. 1.0.0 assumes ml64, while 1.0.1 *probes* if nasm is present, and if
not, falls down
Thanks for the reply. I am trying to understand whether FIPS 180-2 or
FIPS 180-3 is supported in OpenSSL 1.0.1. CHANGES document in
OpenSSL claims the support for FIPS 180-2. However CH is defined in
SHA-256 is #define Ch(x,y,z) (((x) (y)) ^ ((~(x)) (z))) in
SHA-256.c . This is as
As answer on your question whether ml64.exe is existent: when setting
Visual Studio 2010 (SP1) x64 command line environment, ml64.exe is
accessible via the path (in c:\Program Files (x86)\Microsoft Visual
Studio 10.0\VC\bin\amd64\ml64.exe).
Just for the record. Even if ml64 is not
It works.
In all subroutines? Could you double-check? The reason for being
overparticular is that when it comes to compiles bugs, one can expect
*anything*.
Note that you forgot to add it to the BN_nist_mod_521() function, probably
because the variable is named t_d in that function instead of
I was just able to open the link below and the entire document looked okay.
I observe spaces in places where ~ should be in Ch(), not only in
SHA256, but in all of them. And Figure 1 on page 3 is mostly empty...
__
OpenSSL
It is indeed the quoting of the perl command interpreter issue.
I also work often on *nix platforms, and tested with \$^X\, which
worked. But I can’t guarantee that too for all *nix flavors... It may
be worth trying it (unless someone else complains). If you are unsure
for a certain *nix
I tested 2 sample test explained in the FIPS
180-2 and 180-3 documents with OpenSSL 1.0.1 document and test output
matched in both the cases. But the CH was different in FIPS 180-2
than FIPS 180-3. So I was wondering how output can be same
irrespective of CH difference.
There is no way for
[1] S. Gueron, V. Krasnov: Parallelizing message schedules to accelerate the
computations of hash functions, http://eprint.iacr.org/2012/067.pdf
The AVX1 implementation:
The speedup (measured on Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz)
I am trying to compile openssl in solaris 8
I use this :
./Configure --prefix=/soft/nrpe --openssldir=/soft/nrpe no-hw no-zlib
solaris-sparcv8-cc shared
Then make
When I did the make test I met these errors :
CMS consistency test
/usr/bin/perl cms-test.pl
CMS = PKCS#7 compatibility
I have checked out the latest code from
cvs -d anonym...@cvs.openssl.org:/openssl-cvs co openssl
Below is the error message.
sha512-586.s:(.text+0x59): undefined reference to `.L003XOP'
http://cvs.openssl.org/chngview?cn=22638
Core 2 - 950 cycles,
Lynnfiled - 1005,
Sandy Bridge - 936 or 14.6 cbp (!)
P4 Northwood - 1600
On others architectures, including PIII, P4 Prescott, K10 and (I guess,
don't tested) Atom, 1.8 version is better.
http://cvs.openssl.org/chngview?cn=22631
This patch adds the BIO_CTRL_DGRAM_SET_DONT_FRAG option for
BIO_ctrl() to activate the Don't Fragment bit for the current socket,
if possible on the platform.
This a necessary feature to realize a Path MTU Discovery with
Heatbeats and to use SCTP over DTLS for RTCWeb (Real-time Browser to
At least this is what I normally use. The type of *option_value
might be platform dependent, but then we need some #ifdefs for
platforms.
But the choice is still between 32- and 64-bit integers. And if so,
you can distinguish among them at run time as accurately. Or should
one say even
I'm
On side note. Looking at first getsockopt in bss_dgram.c. In non-Windows
case it passes pointer to timeval and says it's sizeof(int) large... How
would non-Windows BIO_CTRL_DGRAM_GET_RECV_TIMEOUT work when ret is
initialized to 1?
Consider http://cvs.openssl.org/chngview?cn=22627. Note that
This patch adds the BIO_CTRL_DGRAM_SET_DONT_FRAG option for
BIO_ctrl() to activate the Don't Fragment bit for the current socket,
if possible on the platform.
This a necessary feature to realize a Path MTU Discovery with
Heatbeats and to use SCTP over DTLS for RTCWeb (Real-time Browser to
Hi Thomas,
we'll have a look at the issue. We are looking into MTU stuff anyway...
Best regards
Michael
On Jun 9, 2012, at 4:10 AM, Tomas Mraz via RT wrote:
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
The getsockopt() for IP_MTU and IPV6_MTU at least on Linux returns a
value of length 4. On little endian systems this is not so critical
problem however on big endian 64 bit systems it means the interpretation
of the returned value by the code in dgram_ctrl() is completely wrong -
Actually
Now I agree ;) 1.8 version is best-balanced for all architectures.
I'm not sure I agree: I've grabbed the 1.8 version and rebuilt openssl
1.0.1c and tested it on an i5
i5 says exactly nothing, please don't use it. Say Nehalem, Sandy Bridge,
whatever, but not i5!
and a Core 2 Duo;
version 11/05/2015:
sha256 39017.64k87648.54k 150106.58k 183705.94k
197330.99k
version 1.8:
sha256 33560.42k73153.83k 121472.43k 167948.67k
180955.23k
It sounds like we're talking about Nehalem, as it's very close to
difference reported by Pavel:
i5
Interleaved are my results translated to your units, basically just
multiplied by 64 and rounded to three significant digits.
1.51.61.71.8my
P III (Coppermime) 1821 / 1850 / 1742 / 1574 / 1614
1540
P4 (Prescott)
http://cvs.openssl.org/chngview?cn=22599
http://cvs.openssl.org/chngview?cn=22600
For reference. As for full unroll I've taken different approach. Instead
of trying to accommodate additional a-h variable in freed register I
keep a^b-b^c in rotating pair of registers instead of stack. And I've
I did observe more than 20% on Opteron, but on Core2/Sandy Bridge
I get only 13-11%...
Well, I've got 984 / 1170 clocks on Core 2 (17%)
and 1033 / 1250 on Core i5 (Westmere) (18%)
Out of curiosity, how fast is updated code from CVS on Westmere?
Sorry, too many codenames. It is Lynnfield.
I
modified the 'Configure' script to allow the compilation of a 32bit
version of openssl *with* the assembly routines.
What does it mean? Configure supports 32-bit builds *with* assembly as
it is. To build 32-bit version on 64-bit Linux, run './Configure
linux-elf -m32'.
The results for this
here are the raw 'openssl speed sha256' results with and without the
patch; all I did was
tar xzf openssl-1.0.0j.tar.gz
cd openssl-1.0.0j.tar.gz
apply patch or not
./Configure linux-elf -m32
make
cd apps
./openssl speed -evp sha256 | grep ^sha
./openssl speed sha256 | grep ^sha
as I promised, here is the optimized code for SHA-256 hash, x86
platform. Should work faster on Core 2/iX up to 20%.
I can't replicate the results, not on Intel CPUs. Well, I can get 20% on
Sandy Bridge if I replace rotate with double precision shift, but it's
not fair comparison (in sense that
With Visual Studio 10 x64, I get the following error at configure time:
...
D:\build.ntx64vs10perl ms\uplink-x86_64.pl masm 1ms\uptable.asm
D:\build.ntx64vs10ml64 -c -Foms\uptable.obj ms\uptable.asm
Assembling: ms\uptable.asm
ms\uptable.asm(356) : error
As I understand from FAQ, this small snippet is needed only if I mixing
compilers for OpenSSL compilation and compilation of my application. But if
I use the same compiler and the same compiler options for OpenSSL
compilation and compilation of my application I don't need this one. Am I
I did observe more than 20% on Opteron, but on Core2/Sandy Bridge
I get only 13-11%...
Well, I've got 984 / 1170 clocks on Core 2 (17%)
and 1033 / 1250 on Core i5 (Westmere) (18%)
Out of curiosity, how fast is updated code from CVS on Westmere?
Anyway, I guess your measurement is more
Currently our customer is getting crash and after analyzing the crash it
shows
Crash dmp analysis report by Debug Dynostic tool 1.2
In WER93CC.tmp.mdmp the assembly instruction at *libeay32+ff22* in *E:\Program
Files\Symphony\WAM\WebEnforcementAgent\one-st.ecolab.com\libeay32.dll* has
I rebooted the box, a IBM 44 Model 170 with a PowerPC_POWER3 CPU with
realmem 2097152, just to make sure there was nothing else affecting
the compile.
I then recompiled using the ./config with no flags. I then ran the
make test and it got into an endless loop (attachment
I originally thought my problem was with ssh, so that is what I was
looking it, after I finally found that the problem was with the ssl, I
sent the email to you. After that I did some more testing and found
that by using the no-asm flag during the config everything worked normally.
I
Is AES performance expected to be much lower when using the FIPS 2.0
Object Module?
Which CPU? You said it's non-AES-NI-capable, but is it SSSE3-capable? If
yes, then see related note at
http://www.mail-archive.com/openssl-dev@openssl.org/msg29827.html.
Below are the speed results when using
I built both a aix 5.2 / 32 bit version of openssl 1.0.1b and a aix 6.1
/ 64 bit version. I also did a build of the latest openssh. When
testing the 32 bit openssh I had some problems that seem to come from
running ssh-keygen.
The aix 6.1 / 64 bit version runs fine with out problems
how come it's not required in all other perlasm modules?
errors do also occure in other perlasm modules, but i'am running this
configure command without asm support which avoids calling other
perlasm modules?
perl Configure debug-VC-WIN64A no-asm --prefix=x64/debug
I have two perl.exe
Hi,
I've been trying to build aes-armv4 for an embedded ARM 9 using the
Green Hills Software tools. In the FIPS canister, the line following
the label .Lok ...
.Lok: stmdb sp!,{r4-r12,lr}
sub r10,r3,#fips_aes_set_encrypt_key-AES_Te-1024@ Te4
gets this error:
[asarm]
Hi,
my testing system is:
Openssl 1.0.1b
Windows 7 64-bit
Nmake compiler-environment
I'am trying to build OpenSSL with the following commands as described in
INSTALL.W64
Perl Configure debug-VC-WIN64A --prefix=x64/debug
call C:\Programme\Microsoft Visual Studio 9.0\VC\vcvarsall.bat
That sounded like it was in another asm file. But I didn't go
through and check to see if the resoultion in that report was
applied to all ASM other files.
Even though it's addressed...it's believed that real culprit is not
OpenSSL, but some other code that incorrectly adds 32-bit value to
Hi,
this patch solve the problem of Program terminated with signal 4,
Illegal instruction on cpu amd geode-lx and VIA Nehemiah?
Is it question or statement?
root@gatto:/tmp# openssl version
Illegal instruction (core dumped)
Is it crash before of after?
root@gatto:/tmp# gdb -c core
Hi,
About a year ago, building on some work by Yoni Londner, I posted
some patches to add more accurate debug information, mostly
describing stack unwinding, to the hand-optimized x86 assembly code.
This is especially helpful when profiling or debugging, since
otherwise the debugger does not
Hi,
i got following error, when building the new openssl-1.0.1a package on a Sun
Solaris 10 operation system with an UltraSPARC cpu:
make[3]: Entering directory `/home/df/openssl-1.0.1a'
[ -z ] || /opt/sunstudio/bin/cc -KPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB
-DOPENSSL_THREADS
Hi,
Attached is a patch that fixes OpenSSL 1.0.1a build problems on a non x86
platform (Sparc).
Addressed in 1.0.1b release.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
Hi,
just tried to compile openssl-1.0.1a on my solaris 10 box, using studio
12.1 compiler, but after
./Configure solaris-sparcv9-cc shared
compilation of openssl-1.0.1a fails (openssl-1.0.1 went ok):
linking of openssl fails with the error:
Undefined symbol OPENSSL_ia32cap_P
first
[openssl-dev@openssl.org - Wed Apr 25 00:33:54 2012]:
Hi,
1.0.0 had this:
/* SSL_OP_ALL: various bug workarounds that should be rather harmless.
* This used to be 0x000FL before 0.9.7. */
#define SSL_OP_ALL 0x8FFFL
1.0.1 now has:
Below is the performance results built with -mcpu=power7. The positive
number shows performance improvements percentage after the branch hint
is removed. The performance test used openssl speed then calculate
the percentage using the results from the branch hint removed and the
results from
I just tried building 1.0.1a on OS X (Lion, if it matters), and it failed
with:
Undefined symbols for architecture x86_64:
_rc4_md5_enc, referenced from:
_rc4_hmac_md5_cipher in libcrypto.a(e_rc4_hmac_md5.o)
ld: symbol(s) not found for architecture x86_64
Looking through the
- sourceforge.net
This one still fails, but I believe that that was caused by the
load balancer of F5 Networks (Big IP).
And there is no good solution for it, except for updating load balancer
software. The only thing one can do otherwise is to minimize ClientHello
by aggressively excluding
Looking at the CVS tree, it looks like this change also doesn't exist
on -head, which means it could break again later. Is this no longer
needed on -head, or is this a problem?
It's *not* and never was needed in HEAD, because rc4_md5_enc is compiled
and works there.
Per your suggestion, I replaced 16+9 with 16 and got the results
attached in the spreedsheet.
I can't read your spreadsheets, not this one nor one you've sent
earlier. It says file corrupted and fails to repair it. Could you send
text instead?
Sorry about that, below is the results.
Could
601 - 700 of 1949 matches
Mail list logo
