harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov (JIRA)" <j...@apache.org>
Subject [jira] Created: (HARMONY-5896) [drlvm] inaccurate 32/31 bit boundary check of 64-bit immediates
Date Fri, 04 Jul 2008 05:02:38 GMT
[drlvm] inaccurate 32/31 bit boundary check of 64-bit immediates
----------------------------------------------------------------

                 Key: HARMONY-5896
                 URL: https://issues.apache.org/jira/browse/HARMONY-5896
             Project: Harmony
          Issue Type: Bug
          Components: DRLVM
         Environment: x86-64
            Reporter: Alexey Varlamov


x86-64 architecture allows 64-bit size immediates only for register initialization, so there
is a typical pattern to workaround like this:
if (fit32(imm)) {
 use_imm_as_32bit
} else {
 move_to_reg
 use_reg
}

However most CPU instructions (MOV, CMP, etc) do _sign extension_ of 32-bit immediates to
64-bit, this may lead to unpredictable errors if highest (32th) bit is set for unsigned values.
Here is the example:

vm/vmcore/src/lil/em64t/m2n_em64t.cpp:307:    
    // store a method associated with the current m2n frame
    bytes_to_m2n_top -= LcgEM64TContext::GR_SIZE;
    if (fit32((int64)method)) {
        buf = mov(buf, M_Base_Opnd(rsp_reg, bytes_to_m2n_top),
            Imm_Opnd(size_32, (int64)method), size_64);
    } else {
        buf = mov(buf, rax_opnd, Imm_Opnd(size_64, (int64)method), size_64);
        buf = mov(buf, M_Base_Opnd(rsp_reg, bytes_to_m2n_top), rax_opnd);
    }


So the problem: all usages of fit32() within the whole VM must be verified and replaced with
fit31() as needed. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message