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)) {
} else {

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:

    // 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.

View raw message