<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm <span dir="ltr"><<a href="mailto:jb-openssl@wisemo.com" target="_blank">jb-openssl@wisemo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22/08/2016 20:09, Scott Ware wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We use libeay32.dll and ssleay32.dll from <a href="https://slproweb.com/products/Win32OpenSSL.htmlin" rel="noreferrer" target="_blank">https://slproweb.com/products/<wbr>Win32OpenSSL.htmlin</a> our applications and we recently moved from version 1.0.2a to 1.0.2g and now on a few machines running a AMD Geode processor we are getting "Unhandled exception at 0x005904dc (libeay32.dll) in Test.exe: 0xC000001D: Illegal Instruction". We ended up building OpennSSL so we could debug into it and found it is failing on "movsd xmm0,mmword" (see below) which the AMD Geode does not seem to support. I have tried "SET OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to change. I may not be using OPENSSL_ia32cap correctly. This happens when calling SSL_CTX_new which then calls RAND_add.<span><br>
<br>
Any ideas on the best thing to do? We don't want to have to manage different compiled versions of libeay32.dll and ssleay32.dll if we can help it.<br>
<br>
</span></blockquote>
Your disassembly looks like the C compiler was invoked with<br>
options that caused regular C floating point code (in this<br>
case, the passing of 45.0 as an argument to RAND_add()) to<br>
be compiled into MMX/SSE instructions instead of backwards<br>
compatible 80x87 floating point instructions or (for simple<br>
cases like this) regular integer unit data movement<br>
instructions (such as two pushes of 32 bit constants that<br>
contain the halves of the 64 bit double constant, which<br>
would have been more efficient on every x86 CPU).<br>
<br>
Did the build scripts or other source code contain any<br>
differences from the official source code that can be<br>
downloaded from <a href="http://openssl.org" rel="noreferrer" target="_blank">openssl.org</a>?<br>
<br>
How did you invoke the build scripts (command sequence,<br>
special build environment, special environment variables<br>
etc.)?<br>
<br>
Which compiler and compiler version/edition did you use?<br>
<br>
It would be interesting to know if one of the common Windows<br>
compilers does this unconditionally, making it unsuitable<br>
for use in programs that need to be backwards compatible.<br>
<br><span><font color="#888888"><br>
</font></span></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">I compiled using this process and seem to be getting the same result as the .dll I downloaded from <a href="http://slproweb.com">slproweb.com</a></div><div class="gmail_extra">I downloaded the 1.0.2g source from <a href="http://openssl.com">openssl.com</a> and didn't change anything.</div><div class="gmail_extra"><br></div><div class="gmail_extra">From the "Developer Command Promt for VS2013"</div>perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg<br>ms\do_ms<br>nmake -f ms\ntdll.mak<br>nmake -f ms\ntdll.mak install<br><div><br></div></div>