On 02/17/2015 10:41 AM, Vladimir Kozlov wrote:
On 2/17/15 10:31 AM, Anthony Scarpino wrote:
On 02/16/2015 06:01 PM, Vladimir Kozlov wrote:
There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed
since it is 32-bit code.
Sure.. Do I still need to save the xmm6 and xmm7 on 32bit code, or is
all of the register saving only for Windows 64bit?
No, in 32-bit you don't need to save xmm6 and xmm7.
Ok, thanks
I see you switched off -DcheckOutput=false for GCM testing and return
from compareArrays() after length compare. Is it because it can't be
done or you did not have time to add needed code?
I'll have to double check, but I believe -DcheckOutput can be turned
back on. I suspect I never updated the @run lines after I changed
compareArrays()
In void compareArrays(byte b[], byte exp[]) {
You have:
+ if (mode.equals("GCM"))
+ return;
for (int i=0; i< exp.length; i++) {
if (b[i] != exp[i]) {
So current changes do not compare arrays elements for GCM. That is why I
asked.
I did this because there are checks in GCM to prevent reusing IVs. The
current design of the hotspot test reuses IVs so that the encrypted or
decrypted result is returned o compare, which is ok for CBC and ECB.
Since I wasn't able to get a reproducible result for GCM, I skipped the
array checking. What I am depending on to test GCM is the TestGHASH
test in the jdk repo, which is a Known Answer Test, to make sure the
GHASH intrinsics are correct to the spec.
All that being said, I will look at this again. I originally didn't
want to completely redesign the hotspot tests when I had TestGHASH
already, but I'll go back to see what changes I can do to hopefully get
compareArrays working.
Tony
