For your information, this happens in code that tries to detect if the
CPU is a model with a slow fmadd instruction, see crypto/sparccpuid.S
According to comments in that code, some UltraSparc-Txxxx CPUs emulate
some of the slow instructions by triggering a slow software emulation.
So, from the parts of your mail that I have kept below, I guess maybe
the UltraSparc T5240 CPU handles fmadd instructions by reporting it
as invalid and then expecting code in SunOS to recognize the situation
and do a software emulation. But when you use a debugger, the SIGILL
signal is reported to the debugger user interface before the builtin
handler deals with it.
I don't know enough about the Solaris debugger to figure out how to
tell it to let the program handle a signal, but I guess there is some
"keep running" command you need to issue a handful of times to get
past this detection code.
On 3/8/2013 12:20 AM, Dennis Clarke wrote:
http://rt.openssl.org/Ticket/Display.html?id=2553
So I will email this into openssl-b...@openssl.org with the basic info.
I am seeing a sigILL when I attempt to debug or
single step through code.
node002 $ uname -a
SunOS node002 5.10 Generic_147147-26 sun4v sparc SUNW,T5240
^^^^^
signal ILL (illegal opcode) in _sparcv9_fmadd_probe at 0xffffffff7e3873fc
0xffffffff7e3873fc: _sparcv9_fmadd_probe+0x000c: fmaddd %f0, %f0, %f2,
%f0
Current function is OPENSSL_cpuid_setup
227 _sparcv9_fmadd_probe();
(dbx) where
[1] _sparcv9_fmadd_probe(0x0, 0x1, 0x2, 0x82, 0xffffffff7e000200, 0x0), at
0xffffffff7e3873fc
=>[2] OPENSSL_cpuid_setup(), line 227 in "sparcv9cap.c"
...
I ALWAYS see this problem when I attempt to use the debugger.
Also seen this way :
node002 $ truss -faeild /usr/local/ssl/bin/openssl version
Base time stamp: 1362175874.0595 [ Fri Mar 1 22:11:14 GMT 2013 ]
...
22956/1: 0.0282 sysinfo(SI_ISALIST, "sparcv9+vis2 sparcv9+vis sparcv9
sparcv8plus+vis2 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc",
257) = 115
...
22956/1: 0.0975 sigfillset(0xFFFFFFFF7E44EC64) = 0
...
22956/1: 0.1003 lwp_sigmask(SIG_SETMASK, 0xFFBFF827, 0x0000FFF7) =
0xFFBFFEFF [0x0000FFFF]
22956/1: 0.1005 sigaction(SIGILL, 0xFFFFFFFF7FFFEA10,
0xFFFFFFFF7FFFEB48) = 0
22956/1: 0.1006 sigaction(SIGBUS, 0xFFFFFFFF7FFFEA10,
0xFFFFFFFF7FFFEB28) = 0
22956/1: 0.1008 Incurred fault #1, FLTILL %pc = 0xFFFFFFFF7EB873FC
22956/1: siginfo: SIGILL ILL_ILLOPC addr=0xFFFFFFFF7EB873FC
22956/1: 0.1009 Received signal #4, SIGILL [caught]
^^^^^^^^
22956/1: siginfo: SIGILL ILL_ILLOPC addr=0xFFFFFFFF7EB873FC
22956/1: 0.1011 lwp_sigmask(SIG_SETMASK, 0xFFBFF82F, 0x0000FFF7) =
0xFFBFFEFF [0x0000FFFF]
22956/1: 0.1012 setcontext(0xFFFFFFFF7FFFDCF0)
22956/1: 0.1013 sigaction(SIGBUS, 0xFFFFFFFF7FFFEA10, 0x00000000) = 0
22956/1: 0.1014 sigaction(SIGILL, 0xFFFFFFFF7FFFEA10, 0x00000000) = 0
22956/1: 0.1015 lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) =
0xFFBFFEFF [0x0000FFFF]
...
(And then the program completes successfully, printing out its version
message)
However this "appears" to run fine :
node002 $ openssl version
OpenSSL 1.0.1e 11 Feb 2013
(Just like it did under truss!)
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, 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 Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
