![]() ![]() Llvm-objdump gives unhelpful output, not indicating the presence of address-size or segment overrides: 0: 0f 01 fa monitorx +-Ġf 01 fa monitorx %rax,%ecx,%edx | monitorxĠf 01 fa monitorx %rax,%ecx,%edx | monitorx %rax, %ecx, %edxĦ7 0f 01 fa monitorx %eax,%ecx,%edx | monitorx %eax, %ecx, %edx # address-size inferred from EAXĦ7 0f 01 fa monitorx %eax,%ecx,%edx | addr32 monitorx # address-size prefixĦ4 0f 01 fa fs monitorx %rax,%ecx,%edx | fs monitorx %rax, %ecx, %edx # segment override works, tooĬlang 13.0.0 with LLVM's built-in assembler / llvm-objdump objdump -d -Matt disassembly (trimmed) | source GNU Binutils objdump chooses to include operands when disassembling into AT&T syntax, unlike with -Mintel. GAS surprisingly uses the same operand-order as Intel syntax, not reversed like you'd expect for AT&T syntax. intel_syntax noprefix objdump -d -Mintel disassembly | sourceĠf 01 fa monitorx | monitorx rax, ecx, edxĦ7 0f 01 fa addr32 monitorx | monitorx eax, ecx, edx # address-size inferred from EAXĦ7 0f 01 fa addr32 monitorx | addr32 monitorx # address-size prefixĦ4 0f 01 fa fs monitorx | fs monitorx rax, ecx, edx # segment override works, too (This is typical of GAS error messages, often less helpful to humans than NASM.) Intel syntax mode. Using ebx or dl for the last operand gave "Error: operand type mismatch for 'monitorx'", which is rather unhelpful because it's not the type that's the problem, it's which register it is. For example, monitorx rax, rcx, dx assembles without complaint. GAS does not check sizes on the last two operands, only that they're some version of ECX, EDX (other than dl/dh). (Or in 32-bit mode, infer 16-bit address size from monitorx ax, ecx, edx) Unlike NASM, GAS does infer the address-size from RAX vs. YASM is too old, hasn't been updated in years. (Backwards, with %rax or %eax as the first operand, not reversed like AT&T syntax should be!) GNU Binutils objdump is the same in -Mintel syntax mode, but lists operands in AT&T mode. Ndisasm -b64 disassembles it as just monitorx, fs monitorx, or a32 monitorx without listing the implicit operands. Segment overrides can be specified with NASM prefixes.Įxample listing from nasm -l/dev/stdout -felf64 foo.asm: 1 00000000 0F01FA monitorxģ 00000006 0F01FA monitorx eax, ecx, edx address-size override not inferred from EAXĤ 00000009 670F01FA a32 monitorx address-size prefix, NASM styleĥ 0000000D 640F01FA fs monitorx rax, ecx, edx segment override works, too ![]() (It's an error to specify RCX or RDX).īut NASM doesn't infer 32-bit address-size in 64-bit mode from using EAX. If specified, the first operand must be EAX or RAX, and the next two must be ECX and EDX. The operand list can be specified or omitted. NASM 2.15.05 (support added for monitorx in version 2.12.01) In the pseudocode example, they use MONITORX EAX, ECX, EDX, but the 32-bit EAX means that's a 32-bit-mode example. (They say there are no hints or extensions defined, so ECX must be 0 else #GP, and EDX is ignored by current CPUs.)įor the address operand, they document it as rAX, which I think means it can be EAX or RAX. The operands can be specified to document the instruction, or in some assemblers to specify an override to the address-size.ĪMD's manual explicitly says that ECX and EDX are 32-bit operands. In assembly syntax, plain monitorx works for most assemblers. In machine code, the operands are implicit. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |