Several bug fixes for the arm32JIT

[Andrew Hughes]

----- Original Message -----
> Hi,
> 
> The following patch fixes several bugs in the arm32jit.
> 
> These bugs were found while resolving an issue with eclipse giving SEGVs
> although only one of them is actually responsible for the SEGV in eclipse.
> 
> Eclipse now seems to run OK.
> 
> I have put the patch at
> 
> http://openjdk.linaro.org/arm32jit/eclipse.patch
> 
> Below is a summary of these bug fixes.
> 
> Ok to push these?
> Ed.
> 
> Bug 1:
> 
>      loc >>= 2;
>      offset = dest - loc;
>      uoff = offset;
> -    if (offset >= -(1<<22) && offset < (1<<22))
> +    if (offset >= -(1<<23) && offset < (1<<23))
>        return out_32(codebuf, A_BL(cond, uoff));
>    }
>    J_Unimplemented();
> 
> The offset was wrong for ARM BL instruction which has 24 bits offset, not 23.
> 
> Bug 2:
> 
>         ldrb    r1, [jpc, lr]
>          bic     ip, ip, #7
>          ldr     pc, [ip, r1, lsl #2]
> +       .set    dispatch_state, 0
>         .endm
> 
> This fixes a compile time error when compiling with FAST_BYTECODES disabled.
> The error was generate by the VOLATILE_VERSION macro.
> 
>         .error "VOLATILE_VERSION macro used before non-volatile
>         DISPATCH_FINISH."
> 
> This was occurring because DISPATCH_BYTECODE was not setting the
> dispatch_state back to 0.
> 
> Bug 3:
> 
>         Opcode  if_acmpeq
>          POP    r2, r3
>          ldrsb   r1, [jpc, #1]
> +        cmp     r3, r2
>          ldrb    r2, [jpc, #2]
> -        cmp     r3, r2
>         beq     branch_taken
>         DISPATCH        3
> 
> (and also in if_acmpne, if_icmplt, if_icmpge, if_icmpgt, if_icmple)
> 
> I am slightly surprise this one has remained undetected for so long!
> Essentially it was comparing against the bytecode it had just loaded rather
> that the TOS element which means that whether the branch was taken or not is
> essentially random.
> 
> However, this is only in the safepoint version of these bytecode, the non
> safe version was OK, so I guess when it was running to safepoints it just
> didn't encounter these. I only noticed this when I disabled
> NOTICE_SAFEPOINTS for debugging which tells it to always use the 'safe'
> version which actually turns out to be not very safe.
> 
> Bug 4:
> 
>         ldr     tmp1, [r2, #4]                          @ rcvr->klass()
> -       tst     r3, #flag_methodInterface
> +       tst     r3, #flag_is_forced_virtual
>         bne     .invokeinterface_methodInterface
> 
> and the corresponding definition of flag_is_forced_virtual in asm_helper.cpp.
> 
> This is the bug that was causing the SEGV in eclipse.
> 
> This bug was caused by the renaming of the flag from flag_methodInterface
> (bit 24) to flag_is_forced_virtual (bit 25) which meant that it was trying
> to do an invokeinterface lookup on a vfinal method and getting a SEGV.
> 
> The change was introduced to bytecodeInterpreter.cpp in change
> 4066:1d7922586cf6.
> 
> changeset:   4066:1d7922586cf6
> parent:      4041:aba91a731143
> user:        twisti
> date:        Tue Jul 24 10:51:00 2012 -0700
> summary:     7023639: JSR 292 method handle invocation needs a fast path for
> compiled code
> 
> However, this change was not reflected in cppInterpreter_arm.S.
> 
> Bug 5:
> 
> +#ifdef FAST_BYTECODES
>         // Common code for fast_aldc and fast_aldc_w
>  # r0 = constpool cache entry
>         .macro  aldc    opc, seq_len
> @@ -3060,7 +3063,6 @@
>          add     r0, constpool, r1, lsl #4
>         aldc opc_fast_aldc_w, 3
> 
> -#ifdef FAST_BYTECODES
>  # r2 = [jpc, #1]
>  # r1 = [jpc, #2]
> 
> Another build failure with FAST_BYTECODES disabled
> 
> Bug 6:
> 
> +       // Ensure that any literals generated in the stubs are output here
> +       // as this code is copied to the bottom of the code buffer
> +       .ltorg
> +
>         .global Thumb2_stubs_end
>         .type Thumb2_stubs_end, %function
>  Thumb2_stubs_end:
> 
> This bug occurred with the volatile version of get_static. Basically, when
> build for ARMv6 this need to call _kernel_dmb because there is no DMB
> instruction. The code to call _kernel_dmb did
> 
> 	ldr	r2, =_kernel_dmb
> 	blx	r2
> 
> This creates an assembler literal which the assembler will dump at the next
> .ltorg (or at the end of the file if no .ltorg).
> 
> However, because the run time stubs are copied to the bottom of the code
> buffer in order to make them reachable from the compiled code, the literal
> was not being copied because the literals were only being dumped after the
> end of the stubs.
> 
> The solution is simply to dump the literal pool before the end of the stubs
> so the literals get copied as well.
> 
> 
> 

Ok by me, unless Andrew Haley or Andrew Dinn have any objections.

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07