为什么 AS 有时接受超大位移有时不接受？答案

【问题标题】：Why does AS sometimes accept oversized displacement and sometimes not?为什么 AS 有时接受超大位移有时不接受？
【发布时间】：2014-06-14 13:59:09
【问题描述】：

我知道 MOD+R/M 字段中的位移最大是一个有符号的 32 位整数。但是，当我传递一个对于 32 位有符号（但对于无符号 32 位来说足够小）的值时，我看到了一些不一致的行为。

例子：

.intel_syntax noprefix
mov [eax + eax + 0xdeadbeef], al
mov [r10d + r10d + 0xdeadbeef], al
mov [rax + rax + 0xdeadbeef], al
mov [r10 + r10 + 0xdeadbeef], al

当我组装（和解散）时，我得到以下结果：

0:  67 88 84 00 ef be ad    mov    BYTE PTR [eax+eax*1-0x21524111],al
7:  de
8:  67 43 88 84 12 ef be    mov    BYTE PTR [r10d+r10d*1-0x21524111],al
f:  ad de
11: 88 04 00                mov    BYTE PTR [rax+rax*1],al
14: 43 88 04 12             mov    BYTE PTR [r10+r10*1],al

可以看出，对于 32 位寄存器（eax，r10d），32 位位移是按字面意思（并解释为带符号的 32 位整数）和 64 位寄存器（@ 987654325@, r10)，丢弃。

虽然我认为两者都是输入的合理输出，但我没有立即看到这种不一致处理的原因。这是否记录在某处？

【问题讨论】：

标签： assembly x86-64 gnu-assembler

【解决方案1】：

似乎是 intel 语法模块中的一个错误。如果您使用 at&t 语法，则会导致错误消息：

mov %al, 0xdeadbeef(%rax, %rax)

结果：

Error: 0xdeadbeef out range of signed 32bit displacement

更新：该错误似乎是因为在调用 i386_finalize_displacement 之后设置了 baseindex 标志，只有在设置了错误时才会检测到错误。一个简单的解决方法是提前移动标志集。我看不出有什么明显的问题，至少解决了这个问题：

--- tc-i386-intel.c.orig        2012-01-16 04:06:06.000000000 +0100
+++ tc-i386-intel.c     2014-06-14 16:13:31.238740524 +0200
@@ -835,6 +835,9 @@
       memcpy (expP, &exp, sizeof(exp));
       resolve_expression (expP);

+      if (intel_state.base || intel_state.index)
+       i.types[this_operand].bitfield.baseindex = 1;
+
       if (expP->X_op != O_constant
          || expP->X_add_number
          || (!intel_state.base
@@ -882,9 +885,6 @@
            return 0;
        }

-      if (intel_state.base || intel_state.index)
-       i.types[this_operand].bitfield.baseindex = 1;
-
       if (intel_state.seg)
        {
          for (;;)

【讨论】：