On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote: > On 22/08/2016 22:33, Scott Ware wrote: > >> >> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm <jb-openssl at wisemo.com >> <mailto:jb-openssl at wisemo.com>>wrote: >> >> On 22/08/2016 20:09, Scott Ware wrote: >> >> We use libeay32.dll and ssleay32.dll from >> https://slproweb.com/products/Win32OpenSSL.htmlin >> <https://slproweb.com/products/Win32OpenSSL.htmlin>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. >> >> 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. >> >> Your disassembly looks like the C compiler was invoked with >> options that caused regular C floating point code (in this >> case, the passing of 45.0 as an argument to RAND_add()) to >> be compiled into MMX/SSE instructions instead of backwards >> compatible 80x87 floating point instructions or (for simple >> cases like this) regular integer unit data movement >> instructions (such as two pushes of 32 bit constants that >> contain the halves of the 64 bit double constant, which >> would have been more efficient on every x86 CPU). >> >> Did the build scripts or other source code contain any >> differences from the official source code that can be >> downloaded from openssl.org <http://openssl.org>? >> >> How did you invoke the build scripts (command sequence, >> special build environment, special environment variables >> etc.)? >> >> Which compiler and compiler version/edition did you use? >> >> It would be interesting to know if one of the common Windows >> compilers does this unconditionally, making it unsuitable >> for use in programs that need to be backwards compatible. >> >> >> >> I compiled using this process and seem to be getting the same result as >> the .dll I downloaded from slproweb.com <http://slproweb.com> >> I downloaded the 1.0.2g source from openssl.com <http://openssl.com>and >> didn't change anything. >> >> From the "Developer Command Promt for VS2013" >> perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg >> ms\do_ms >> nmake -f ms\ntdll.mak >> nmake -f ms\ntdll.mak install >> > According to the following page > > https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx > > Visual Studio 2012 and later requires the following compiler > option to generate code compatible with older CPUs (this is the > default in Visual Studio 2010, and VS2010 does not support the > option): > > /arch:IA32 > > > This compiler gotcha is specific to the 32 bit x86 architecture, > the default looks like it is still sane for x86_64. > > Note to the FIPS team: Please check if this affects the FIPS > module building procedure. Jakob! Thank you so much! That was the issue.I added /arch:IA32 to the APP_CFLAG and LIB_CFLAG in ms\ntdll.mak and I was able to compile a new build that works on the problem machine. Is it worth doing a bug report on so they might add that to the build scripts? Without it it seems like the whole OPENSSL_ia32cap system is broken. Before I had found this answer I had also installed nasm so I didn't have to do the no-asm. So My current build process is: >From the "Developer Command Promt for VS2013" perl Configure VC-WIN32 --prefix=C:\OpenSSL-VC-32-DLL ms\do_ms ms\do_nasm.bat (Edit ms\ntdll.mak to add /arch:IA32 to the APP_CFLAG and LIB_CFLAG) nmake -f ms\ntdll.mak nmake -f ms\ntdll.mak install Thank you Jakob and the OpenSSL mailing list for the quick answers! - Scott Ware -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160823/3cada41b/attachment.html>
