You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Alexey Varlamov (JIRA)" <ji...@apache.org> on 2008/07/04 07:02:38 UTC
[jira] Created: (HARMONY-5896) [drlvm] inaccurate 32/31 bit
boundary check of 64-bit immediates
[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.
[jira] Commented: (HARMONY-5896) [drlvm] inaccurate 32/31 bit
boundary check of 64-bit immediates
Posted by "Ilya Berezhniuk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-5896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614153#action_12614153 ]
Ilya Berezhniuk commented on HARMONY-5896:
------------------------------------------
The bug is quite serious - such 'signed' 32-bit values actually appear in real situations.
Similar problem with sign extending was fixed in HARMONY-5789.
> [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.