Assembly Insight debugger在寄存器中显示错误的值

我正在64位Mac-to-Linux计算机上使用Insight调试器

它告诉我，mov ebx，1739的结果是ebx中的0xcc00cccb。EAX获得了预期的0x1bf，但乘法结果也很奇怪（当它应该放入32位寄存器时）

拜托，有人告诉我发生了什么事。我甚至不能声明一个databyte字符串，除非它做一个类似的效果，即向任何mov或mul指令生成的任何十六进制中添加几个高阶半字节的c，无论哪个寄存器先声明。我使用NASM汇编程序

编辑：我要汇编和链接的两个终端条目是：

nasm -f elf -g -F stabs test.asm -l test.lst
ld -o test test.o -melf_i386

对于任何可能运行Ubuntu 16.04 LTS的人来说，如果你试图通过博客文章中建议的方法“找回”从Ubuntu默认应用程序集中删除的Insight： ，您将无法实际获得您希望的应用程序。它缺了几块

从表面（界面）上看，这似乎是可行的，但可能只是做了一些修补工作，无法完全重新生成应用程序

---

真正的原因与我的计算机某个地方的内部故障有关，由于未知原因，如果保存程序集文件的文件夹名为“assembly”，则无法将值正确分配给寄存器

mul

之后的结果是什么？eax的值更改为0x35659675，edx从0x0更改为0x164，eflags也更改了，但我假设这是进位标志。您是将其编译为64位程序还是32位程序？我的两个终端条目是：nasm-f elf-g-f stabs test.asm-l test.lst…和。。。。ld-o测试。o-melf_i386; i让它运行。你完全正确。它是Insight调试器。GDB说ebx寄存器是0x6cb，等于1739。非常感谢你！我会得到DDD，如果它比GDB更容易（我更喜欢有一个界面来方便导航），我这里有一个Ubuntu 16.04 LTS系统。我完全按照网页上的说明进行操作，当我在可执行文件上运行

insight

时，通过程序，寄存器有正确的值，MUL有正确的结果。那么，为什么我从insight得到如此奇怪的响应，而不是从GDB得到的？您是否像我那样组装和链接.asm文件？是否建议通过屏幕共享进行此操作？我很乐意和你分享我的屏幕。如果这样的建议违反了规则，请提前道歉。当我这样做时，我将其组装并链接到构建insight的目录之外的可执行文件。当您完成构建isight时，是否进行了sudo make安装。您可能希望执行的其他操作是确保正在调试的程序位于当前目录中。例如，最好执行

isight./test

强制isight在当前目录中使用程序

test

，而不是潜在地使用

/usr/bin/test

中的系统定义的程序。您不需要从存储库所在的目录运行它。在我的系统上，我将您的代码放在一个完全不同的文件夹中，将其组装并链接，可执行文件不在存储库文件夹中。所以我觉得你还是做错了什么。

nasm -f elf -g -F stabs test.asm -l test.lst
ld -o test test.o -melf_i386