Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Scott Ware]

On Fri, Aug 26, 2016 at 2:10 AM, Thomas J. Hruska
 wrote:
> Then push a request upstream to change the default build settings. Don't
> blame me.  The binaries that are built are built strictly with default
> settings with the only exception being the various funky runtime linker
> options (/MD, /MT, etc).  If you don't like the defaults, then get the
> upstream changed.
>

Hey Thomas!

Actually the people to blame is Microsoft. They changed the behavior
of Visual Studio. VS2008 was fine, but now  in VS2012 and above SSE is
enabled by default.
https://msdn.microsoft.com/en-us/library/7t5yh4fd(v=vs.110).aspx

I will work with the Configure scripts and see if I can find a
solution to detect the version of VS and add the flag for VS2012 and
above and then try to get it accepted.

-Scott Ware
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Thomas J. Hruska]

On 8/25/2016 9:21 PM, Jakob Bohm wrote:

On 26/08/2016 05:42, Scott Ware wrote:

On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm 
wrote:

On 22/08/2016 22:33, Scott Ware wrote:

On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm >wrote: On 22/08/2016 20:09, Scott
Ware wrote: We use libeay32.dll and ssleay32.dll from
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: 0xC01D:
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=~0x100", "SET OPENSSL_ia32cap=~0x200",
and "SET OPENSSL_ia32cap=~0x700"; 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 ?
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  I downloaded the 1.0.2g source
from 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.

Well, I tried to get my normal distribution source to compile with
/arch:IA32. Didn't go well. :( On Thu, Aug 25, 2016 at 10:12 PM,
Thomas J. Hruska  wrote:

On 8/23/2016 7:19 AM, Scott Ware wrote:

Shining Light Productions, Would you consider implementing this in
your builds? VS2012 and above require the /arch:IA32 flag to produce
x86 code compatible with older CPUs.
https://mta.openssl.org/pipermail/openssl-users/2016-August/004260.html
Thanks, Scott Ware



This is an upstream issue. I only do default builds. Contact the
OpenSSL developers if you want that flag added to the default build
process. SSE2 is the default target architecture for Visual Studio
when /arch is not specified. If you don't have a CPU with SSE2
instruction support, then it is long past due for a hardware upgrade.



Bad on them, those of us that have seen this kind of hardware
all know that Geode CPUs use very very little power compared
to modern Intel CPUs, less even than most of Intel's "Atom"
CPUs.


Then push a request upstream to change the default build settings. 
Don't blame me.  The binaries that are built are built strictly with 
default settings with the only exception being the various funky runtime 
linker options (/MD, /MT, etc).  If you don't like the defaults, then 
get the upstream changed.


--
Thomas Hruska
Shining Light Productions

Home of BMP2AVI and Win32 OpenSSL.
http://www.slproweb.com/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Jakob Bohm]

On 26/08/2016 05:42, Scott Ware wrote:
On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm  
wrote:

On 22/08/2016 22:33, Scott Ware wrote:
On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm >wrote: On 22/08/2016 20:09, Scott 
Ware wrote: We use libeay32.dll and ssleay32.dll from 
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: 0xC01D: 
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=~0x100", "SET OPENSSL_ia32cap=~0x200", 
and "SET OPENSSL_ia32cap=~0x700"; 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 ? 
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  I downloaded the 1.0.2g source 
from 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. 
Well, I tried to get my normal distribution source to compile with 
/arch:IA32. Didn't go well. :( On Thu, Aug 25, 2016 at 10:12 PM, 
Thomas J. Hruska  wrote:

On 8/23/2016 7:19 AM, Scott Ware wrote:
Shining Light Productions, Would you consider implementing this in 
your builds? VS2012 and above require the /arch:IA32 flag to produce 
x86 code compatible with older CPUs. 
https://mta.openssl.org/pipermail/openssl-users/2016-August/004260.html 
Thanks, Scott Ware 
This is an upstream issue. I only do default builds. Contact the 
OpenSSL developers if you want that flag added to the default build 
process. SSE2 is the default target architecture for Visual Studio 
when /arch is not specified. If you don't have a CPU with SSE2 
instruction support, then it is long past due for a hardware upgrade. 
-- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 
OpenSSL. http://www.slproweb.com/

Bad on them, those of us that have seen this kind of hardware
all know that Geode CPUs use very very little power compared
to modern Intel CPUs, less even than most of Intel's "Atom"
CPUs.

I have a Geode SC1100 based server running 24/7 at 266MHz
using less than about 7W peak with no heatsink.  Even a
real 486DX @33MHz couldn't do that.  This server actually
replaced a 486DX @33MHz to save power and was not upgraded
to a more power hungry successor product based on an Atom.

This is clearly a compiler misfeature in the VS2012+ compiler,
which assumes by default the compiled binaries will only be
used on desktop or higher class CPUs that can run Windows 8,
not on pared down CPUs that are designed for power saving
embedded Windows.

But anyway, just doing your own scripted builds instead of
waiting for 

Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Scott Ware]

On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm  wrote:
> On 22/08/2016 22:33, Scott Ware wrote:
>>
>>
>> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm > >wrote:
>>
>> On 22/08/2016 20:09, Scott Ware wrote:
>>
>> We use libeay32.dll and ssleay32.dll from
>> 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: 0xC01D: 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=~0x100", "SET OPENSSL_ia32cap=~0x200",
>> and "SET OPENSSL_ia32cap=~0x700"; 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 ?
>>
>> 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 
>> I downloaded the 1.0.2g source from 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.


Well, I tried to get my normal distribution source to compile with /arch:IA32.
Didn't go well. :(

On Thu, Aug 25, 2016 at 10:12 PM, Thomas J. Hruska
 wrote:
> On 8/23/2016 7:19 AM, Scott Ware wrote:
>>
>> Shining Light Productions,
>>   Would you consider implementing this in your builds? VS2012 and
>> above require the /arch:IA32 flag to produce x86 code compatible with
>> older CPUs.
>>
>> https://mta.openssl.org/pipermail/openssl-users/2016-August/004260.html
>>
>> Thanks,
>> Scott Ware
>
>
> This is an upstream issue.  I only do default builds.  Contact the OpenSSL
> developers if you want that flag added to the default build process.
>
> SSE2 is the default target architecture for Visual Studio when /arch is not
> specified.  If you don't have a CPU with SSE2 instruction support, then it
> is long past due for a hardware upgrade.
>
> --
> Thomas Hruska
> Shining Light Productions
>
> Home of BMP2AVI and Win32 OpenSSL.
> http://www.slproweb.com/
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Scott Ware]

On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm  wrote:

> On 22/08/2016 22:33, Scott Ware wrote:
>
>>
>> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm > >wrote:
>>
>> On 22/08/2016 20:09, Scott Ware wrote:
>>
>> We use libeay32.dll and ssleay32.dll from
>> 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: 0xC01D: 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=~0x100", "SET OPENSSL_ia32cap=~0x200",
>> and "SET OPENSSL_ia32cap=~0x700"; 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 ?
>>
>> 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 
>> I downloaded the 1.0.2g source from 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Jakob Bohm]

On 22/08/2016 22:33, Scott Ware wrote:


On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm >wrote:


On 22/08/2016 20:09, Scott Ware wrote:

We use libeay32.dll and ssleay32.dll from
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: 0xC01D: 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=~0x100", "SET OPENSSL_ia32cap=~0x200",
and "SET OPENSSL_ia32cap=~0x700"; 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 ?

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 
I downloaded the 1.0.2g source from 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.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Scott Ware]

On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm  wrote:

> On 22/08/2016 20:09, Scott Ware wrote:
>
>> We use libeay32.dll and ssleay32.dll from 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:
>> 0xC01D: 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=~0x100", "SET OPENSSL_ia32cap=~0x200", and "SET
>> OPENSSL_ia32cap=~0x700"; 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?
>
> 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
I downloaded the 1.0.2g source from 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Jakob Bohm]

On 22/08/2016 20:09, Scott Ware wrote:
We use libeay32.dll and ssleay32.dll from 
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: 0xC01D: 
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=~0x100", "SET OPENSSL_ia32cap=~0x200", and 
"SET OPENSSL_ia32cap=~0x700"; 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?

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.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users