为什么NASM16位模式下的‘`add cx，1234`会产生带有objdump的<unknown>？
为什么NASM16位模式下的‘`add cx，1234`会产生带有objdump的<unknown>？
提问于 2021-01-29 03:42:23
我有这个：
bits 16
global start
section .text
start:
add cx, 1234使用这个Makefile：
test:
@nasm -f macho64 test.asm
@objdump -x86-asm-syntax=intel --full-leading-addr -d test.o
.PHONY: test它打印：
% make
test.o: file format Mach-O 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 start:
0: 81 c1 <unknown>
2: d2 04 <unknown>为什么它会生成<unknown>，而不在这里显示指令？我做错什么了吗？我还在学习机器代码的基础知识，如果很明显的话，很抱歉。
它在32位模式下似乎工作得很好：
bits 32
global start
section .text
start:
add cx, 1234输出：
% make
test.o: file format Mach-O 64-bit x86-64
Disassembly of section __TEXT,__text:
0000000000000000 start:
0: 66 81 c1 d2 04 add cx, 1234回答 1
Stack Overflow用户
回答已采纳
发布于 2021-01-29 04:13:14
64位模式下的操作码81需要更多5个字节(modrm + imm32)，但是您的.text段在此之前结束，所以反汇编程序放弃了。如果你用更多的字节填充文本部分(比如times 10 db 0)，你会得到一些东西。
您使用bits 16将非64位机器码放入64位目标文件中，因此，您当然应该预料到通常会出现错误。
16位模式的默认操作数大小(16)不同于32和64位模式的默认操作数大小(32)，因此66操作数大小前缀与之相反。在32位或64位模式(如add cx, 1234)中需要66前缀的指令要求在16位模式中不存在该前缀。(正如您上一个问题的@fuz's answer中所述)
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/65948483
复制
![因《设计模式》产生的误解[《软件方法》节选]](https://ask.qcloudimg.com/http-save/yehe-6288414/6a4d3e0e1a9fff2c6cca2644eb4e5921.png)
相似问题
带有调试信息的二进制文件的objdump会产生错误的输出。
为什么这个带有内存的MOV和ADD序列会产生AX=90FFh？
为什么代码会产生400错误，但在调试模式下运行？
在docker下运行objdump会显示不同的结果。
屏蔽上位或下4位会产生相同的图像。
添加站长 进交流群
领取专属 10元无门槛券
AI混元助手 在线答疑
关注 腾讯云开发者公众号
洞察 腾讯核心技术
剖析业界实践案例
腾讯云开发者
