On 12/26/13 3:29 PM, David Miller wrote:
From: Misaki Miyashita <misaki.miyash...@oracle.com>
Date: Thu, 26 Dec 2013 15:11:49 -0800 (PST)
Checking for chip capabilities by calling an invalid instruction
causes an issue especially when people run debugger with an OpenSSL
application.
As has already been discussed in this thread, that's a debugger
problem.
Please consider determining the chip capabilities for SPARC by
calling getisax(2) instead of causing and catching SIGILL. (For
RNG, we'll never support the random instruction, and it can be just
removed).
Again, as already discussed in this thread, the SIGILL technique
is portable across all operating systems, whereas getisax() is
not.
I really think you should work on getting the debugger to cope with
this SIGILL signal cleanly, rather than continuing to beat a dead
horse here. This technique is quite common across libraries that
need to test for cpu instruction availability.
Hi David -
both Dan and Misaki have noted, though, that this specific SPARC
instruction OpenSSL is checking for never existed and will never
exist in any SPARC chipset that Sun/Oracle shipped. Could we at
least remove that check? That capability does not and will not
exist, so it seems a waste of cycles to check (and confuses users,
we get lots of questions about this specific instruction and
why it doesn't work or which platform it should work on)
Does that make sense? thanks!
Valerie
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
