movq %rcx, %gs:0x80000000不能通过编译

今天有同事提问, 为什么

movq %rcx, %gs:0x7fffffff //可以通过编译
movq %rcx, %gs:0x80000000 //不能通过编译

其实就是一个立即数的差别, 应该是无差的, 好吧, 让我们来研究一下

第一步

先看一下movq %rcx, %gs:0x7fffffff的二进制指令, 因为movq %rcx, %gs:0x80000000不能通过编译, 就不是合法指令, 自然也看不了二进制内容了

  1c:   65 48 89 0c 25 ff ff    mov    %rcx,%gs:0x7fffffff
  23:   ff 7f

第二步

既然65 48 89 0c 25 ff ff ff 7f是mov %rcx,%gs:0x7fffffff, 很容易得到前面65 48 89 0c 25是mov %rcx,%gs, 后面是一个立即数, 那么我们就看看65 48 89 0c 25 80 00 00 00是什么东西

第三步

怎么知道65 48 89 0c 25 80 00 00 00是什么东西呢?
打开o文件, 找到指令的编码位置, 把7f ff ff ff 改成 80 00 00 00, 然后再objdump, 得到

  1c:   65 48 89 0c 25 00 00    mov    %rcx,%gs:0xffffffff80000000
  23:   00 80

由此我们可以得到, 65 48 89 0c 25后面的4字节会被解释成signed int, 再来验证一下, 编译一下mov %rcx,%gs:0xffffffff80000000可以得到65 48 89 0c 25 00 00 00 80

可以得到结论, movq %rcx, %gs:0x80000000被gcc理解成了movq %rcx, %gs:0x0000000080000000

第四步

下面的问题就是为什么movq %rcx, %gs:0x0000000080000000是非法指令
其中一个很容器想到的答案就是, 原来指令65 48 89 0c 25后面是跟4字节的, 现在变成8字节了, 如果还是这种模式的话, 变成了13字节, 应该是太长了, 所以65 48 89 0c 25要变成更短的东西, opcode和register的选择也没这么随意了, 下面的事情就是去查手册了, 还有一种偷懒的方式就是把rcx换成其他寄存器, 把所有的寄存器都试一遍, 看看行不行

结论

movq %r?x, %gs:0x0000000080000000只能使用rax

movq %rcx, %gs:0x7fffffff, movq %rcx, %gs:0x80000000是被编码成64位基地址和32位整数或者64位整数相加,

先讨论位编码成32位整数的情况,

如果我是设计师的话, 也倾向于把后面的这个32位设计成signed, 这样寻址过程中, 又能向前, 又能向后

所以movq %rcx, %gs:0x7fffffff是合法的

movq %rcx, %gs:0x80000000 gcc报告错误是因为这个等价于movq %rcx, %gs:0x0000000080000000, 0x0000000080000000已经超出32位signed的范围了, 不能编码成64位基地址和32位整数相加, 只能编码成64位基地址和64位整数相加

这样后面的这个64位整数就要被编码进指令里面去, 比之前的指令多了4个字节, 所以前面的寄存器, opcode的编码就少了, 不能随意的选择寄存器, 只能默认rax来操作, 也就是mov变成了movabs

所以movq %rax, %gs:0x80000000是合法的