我什么时候应该在 x86 中使用 size 指令? [英] When should I use size directives in x86?

查看:24
本文介绍了我什么时候应该在 x86 中使用 size 指令?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

何时在 x86 中使用 size 指令似乎有点模棱两可.此 x86 组装指南 内容如下:

When to use size directives in x86 seems a bit ambiguous. This x86 assembly guide says the following:

一般来说,给定内存中数据项的预期大小地址可以从它所在的汇编代码指令中推断出来参考.例如,在上述所有指令中,大小可以从寄存器的大小推断出内存区域操作数.当我们加载 32 位寄存器时,汇编器可以推断我们所指的内存区域是 4 字节宽.当我们将一个字节寄存器的值存储到内存时,汇编器可以推断出我们希望地址指向单个内存中的字节.

In general, the intended size of the of the data item at a given memory address can be inferred from the assembly code instruction in which it is referenced. For example, in all of the above instructions, the size of the memory regions could be inferred from the size of the register operand. When we were loading a 32-bit register, the assembler could infer that the region of memory we were referring to was 4 bytes wide. When we were storing the value of a one byte register to memory, the assembler could infer that we wanted the address to refer to a single byte in memory.

他们给出的示例非常简单,例如将立即数移动到寄存器中.
但是对于更复杂的情况,例如以下情况呢:

The examples they give are pretty trivial, such as mov'ing an immediate value into a register.
But what about more complex situations, such as the following:

mov    QWORD PTR [rip+0x21b520], 0x1

在这种情况下,QWORD PTR size 指令不是多余的,因为根据上述指南,可以假设我们想要将 8 个字节移动到目标寄存器中,因为 RIP 是 8 个字节?x86 架构上大小指令的最终规则是什么?我在任何地方都找不到答案,谢谢.

In this case, isn't the QWORD PTR size directive redundant since, according to the above guide, it can be assumed that we want to move 8 bytes into the destination register due to the fact that RIP is 8 bytes? What are the definitive rules for size directives on the x86 architecture? I couldn't find an answer for this anywhere, thanks.

更新:正如罗斯所指出的,上面例子中的目的地不是寄存器.这是一个更相关的例子:

Update: As Ross pointed out, the destination in the above example isn't a register. Here's a more relevant example:

mov    esi, DWORD PTR [rax*4+0x419260] 

在这种情况下,难道不能假设我们要移动 4 个字节,因为 ESI 是 4 个字节,从而使 DWORD PTR 指令变得多余吗?

In this case, can't it be assumed that we want to move 4 bytes because ESI is 4 bytes, making the DWORD PTR directive redundant?

推荐答案

你说得对;它比较含糊.假设我们在谈论 Intel 语法,确实可以使用 size 指令经常逃脱.任何时候汇编程序可以自动计算出来,它们都是可选的.例如,在指令

You're right; it is rather ambiguous. Assuming we're talking about Intel syntax, it is true that you can often get away with not using size directives. Any time the assembler can figure it out automatically, they are optional. For example, in the instruction

mov    esi, DWORD PTR [rax*4+0x419260] 

DWORD PTR 说明符是可选的,这正是您所假设的原因:汇编器可以确定它要移动一个 DWORD 大小的值,因为该值正在移动到一个 DWORD 大小的寄存器中.

the DWORD PTR specifier is optional for exactly the reason you suppose: the assembler can figure out that it is to move a DWORD-sized value, since the value is being moved into a DWORD-sized register.

同样,在

mov    rsi, QWORD PTR [rax*4+0x419260] 

出于完全相同的原因,QWORD PTR 说明符是可选的.

the QWORD PTR specifier is optional for the exact same reason.

但它并不总是可选的.考虑你的第一个例子:

But it is not always optional. Consider your first example:

mov    QWORD PTR [rip+0x21b520], 0x1

这里,QWORD PTR 说明符不是可选.没有它,汇编器不知道您要存储从地址 rip+0x21b520 开始的大小值.0x1 应该存储为 BYTE 吗?扩展为 WORD?一个双字?一个QWORD?一些汇编程序可能会猜测,但如果不明确指定您想要什么,您就无法确定正确的结果.

Here, the QWORD PTR specifier is not optional. Without it, the assembler has no idea what size value you want to store starting at the address rip+0x21b520. Should 0x1 be stored as a BYTE? Extended to a WORD? A DWORD? A QWORD? Some assemblers might guess, but you can't be assured of the correct result without explicitly specifying what you want.

换句话说,当值在寄存器操作数中时,大小说明符是可选的,因为汇编程序可以根据寄存器的大小计算出大小.但是,如果您处理的是立即数或内存操作数,则可能需要使用大小说明符来确保获得所需的结果.

In other words, when the value is in a register operand, the size specifier is optional because the assembler can figure out the size based on the size of the register. However, if you're dealing with an immediate value or a memory operand, the size specifier is probably required to ensure you get the results you want.

就我个人而言,我更喜欢在编写代码时总是包含大小.打字要多几个字符,但它迫使我思考并明确说明我想要什么.如果我搞砸了并编写了不匹配的代码,那么汇编器会大声地对我尖叫,这已经不止一次地发现了错误.我也认为把它放在那里可以提高可读性.所以在这里我同意 old_timer,尽管他的观点似乎有点不受欢迎.

Personally, I prefer to always include the size when I write code. It's a couple of characters more typing, but it forces me to think about it and state explicitly what I want. If I screw up and code a mismatch, then the assembler will scream loudly at me, which has caught bugs more than once. I also think having it there enhances readability. So here I agree with old_timer, even though his perspective appears to be somewhat unpopular.

反汇编器的输出也往往很冗长,包括大小说明符,即使它们是可选的.Hans Passant 在评论中推测这是为了保持与总是需要这些的老式汇编器的向后兼容性,但我不确定这是真的.这可能是其中的一部分,但根据我的经验,反汇编程序往往以很多不同的方式冗长,我认为这只是为了更容易分析您不熟悉的代码.

Disassemblers also tend to be verbose in their outputs, including the size specifiers even when they are optional. Hans Passant theorized in the comments this was to preserve backwards-compatibility with old-school assemblers that always needed these, but I'm not sure that's true. It might be part of it, but in my experience, disassemblers tend to be wordy in lots of different ways, and I think this is just to make it easier to analyze code with which you are unfamiliar.

请注意,AT&T 语法使用了稍微不同的技巧.它不是将大小写为操作数的前缀,而是为指令助记符添加后缀:b 为字节,w 为字,l 表示 dword,q 表示 qword.所以,前面的三个例子变成了:

Note that AT&T syntax uses a slightly different tact. Rather than writing the size as a prefix to the operand, it adds a suffix to the instruction mnemonic: b for byte, w for word, l for dword, and q for qword. So, the three previous examples become:

movl    0x419260(,%rax,4), %esi
movq    0x419260(,%rax,4), %rsi
movq    $0x1, 0x21b520(%rip)

同样,在前两条指令中,lq 前缀是可选的,因为汇编器可以推断出合适的大小.在最后一条指令中,就像在 Intel 语法中一样,前缀是非可选的.因此,AT&T 语法与 Intel 语法中的内容相同,只是大小说明符的格式不同.

Again, on the first two instructions, the l and q prefixes are optional, because the assembler can deduce the appropriate size. On the last instruction, just like in Intel syntax, the prefix is non-optional. So, the same thing in AT&T syntax as Intel syntax, just a different format for the size specifiers.

这篇关于我什么时候应该在 x86 中使用 size 指令?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆