RFR(S) 8021296 : [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases

Yumin Qi yumin.qi at oracle.com
Mon Jul 29 17:04:30 PDT 2013


On 7/26/2013 5:58 PM, Dean Long wrote:
> This looks wrong.  For 32-bit, you probably want REG_EIP, and to 
> change the "6" into the correct instruction size for x86.
Agree it should be REG_EIP.
> Or disable the test for 32-bit.  Otherwise the comment:
>
>   43     // Move forward to skip failing instruction
>
> isn't correct and you won't skip the failing instruction.
>
I think it does not matter here for a test case since this handler never 
executed in test case. It only tests if installing the signal handler 
for a sig no > MAXSIGNUM works.
The ip stored in

context->uc_mcontext.gregs[TEST_REG];

Is the one when sig was raised, and when signal handler returns, it 
should go back to
context->uc_link->uc_mcontext.gregs[TEST_REG];

I don't understand why set context->uc_mcontext.gregs[TEST_REG] here 
since it will not take this address when signal handler returns.  Since 
we have no idea what the size of next instruction is, 6 is not a good 
number anyway. As a test case, just a print out message is OK. So we can 
just remove the setting.

Yumin
> On 7/26/2013 4:06 PM, Calvin Cheung wrote:
>> Please review this small fix for a testcase bug.
>>
>> webrev: http://cr.openjdk.java.net/~ccheung/8021296/webrev/
>>
>> JBS: https://jbs.oracle.com/bugs/browse/JDK-8021296
>> bug: http://bugs.sun.com/view_bug.do?bug_id=8021296
>>
>> Fixing 2 issues:
>> 1) gcc not found on the test machine
>>     In the sh script, check for if gcc exists. If it doesn't exist, 
>> declare the test as "Passed".
>> 2) REG_RIP undeclared
>>     REG_RIP is only defined for 64-bit linux. The compile failure was 
>> seen on 32-bit platform.
>>     The fix is to check for 64-bit platform - use REG_RIP for 64-bit 
>> and REG_EFL for 32-bit.
>>     They both have a value of 16.
>>
>> Testing:
>>     Ran jtreg on the testcases and making sure it reports "Passed" if 
>> gcc isn't found.
>>
>> thanks,
>> Calvin
>>
>>
>>
>>
>



More information about the hotspot-runtime-dev mailing list