ARM: fix java.lang.Math.log10

[Andrew Haley]

On 01/17/2012 12:28 PM, Xerxes Rånby wrote:
> 2012-01-16 19:41, Andrew Haley skrev:
>> In JCK testing we discovered that java.lang.Math.log10 causes a crash.
>>
>> In HotSpot there is a special table of method kinds, and it was
>> updated to include java.dyn.MethodHandles::invoke.  Unfortunately,
>> this entry was added in the middle of the list, rather than at the
>> end, so the java.lang.Math.* entries all move up by one.
>> java.lang.Math.log10 was at the end of the table, and it fell off.
>> :-)
> 
> I have verified that your patch do make java.lang.Math.log10 work for the ARM asm interpreter.
> This patch are OK for icedtea6 HEAD and icedtea6-1.11.
> 
> Some observations that need attention:
> 
> (oddity no 1)
> Interesting... The crash itself are still not explained.
> When java.lang.Math.log10 "entry no 15" fall of the end of the list then it make the whole function return 0.
> The Zero cpp interpreter will notice this and installs its own non-asm version of java.lang.Math.log10 as fall-back.
> See: openjdk/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp AbstractInterpreterGenerator::generate_method_entry .
> 
> The crash triggers after the Zero c++ fall-back entry for java.lang.Math.log10
> have both executed and returned.
> To me this indicate that something in the inter-working between the c++ Zero interpreter
> and the asm Zero interpreter are still broken.

It's not broken, it just does not work.  The reason it doesn't work is
this code that's ifndef SHARK:

normal_dispatch_and_return:
	mov	r0, tmp2
	mov	r1, ip
#ifndef SHARK
	add	r3, r3, #CODE_ALIGN_SIZE
#endif
	mov	r2, tmp1
	blx	r3

In other words, CODE_ALIGN_SIZE (64) is added to the program counter,
and we enter CppInterpreter::normal_entry + 64.

So, because of this offset of 64 there are no circumstances in which
it's ever correct to call CppInterpreter::normal_entry from the ARM
asm interpreter.  Maybe we should abort in that case.

> (oddity no 2)
> When installing vm_fatal_error as entry to handle the "java.dyn.MethodHandles::invoke" causes a signal 11
> I would have expected it to call report_should_not_reach_here and exit cleanly.
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (os_linux_zero.cpp:270), pid=11232, tid=1090544752
> #  fatal error: caught unhandled signal 11

I'll fix that if you can provide a test case.

Andrew.