> I ran the truss command line you specified on the Sun T-3 and had to kill -9 > the process as Ctrl-C and Ctrl-Z did not work. Attached is the truss.log > output and below are the last few lines of that file where the process was > hung up.
truss.log also effectively confirms the hypotheses. > Setting OPENSSL_sparcv9cap to "0x20" (or even "0") allowed the program to > complete (the code looks like it bypasses the probes if this is set to > anything), though I don't know the operational ramifications of any value. You're correct that variable in question bypasses capability detection. Whole idea behind capability detection is to provide best performance. But setting wrong value can also cause crashes [because you'd be effectively forcing CPU to execute instructions it doesn't support]. For reference 0x20 is value that would normally have been set on T3 and means "use VIS3 extensions". The referred extensions are used for GHASH (~4.5x improvement) and BN (~2x improvement for RSA2048). Improvement coefficients are for T3 and relative to OPENSSL_sparcv9cap being set to 0. > I applied the patch you sent and configured/compiled using > "solaris-sparcv9-gcc" and the program completes normally. > > As I am unable to use patched/unofficial code for our operational needs, What is criteria for being "official"? Explicitly released as tar-ball or just commit to repository? > what I did last week is use the following option to the OpenSSL Configure > script "solaris-sparcv7-gcc" or "solaris-sparcv7-cc" (we use both GCC and Sun > C) and that seemed to fix/bypass the problem on the T-3. That would do the trick, but under the circumstances you would be better off configuring with no-asm. This way you at least tell compiler to target SPARCv9. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
