Linux 为什么gdb以这种方式打印寄存器值

所以我有一个任务，我必须用32位寄存器比较128位的数字。所以我想检查一下左边的每一位，并将其与其他数字进行比较。我有这样的情况：

我有一个.txt文件，其中有两个16字节的数字，没有空格或换行符，如下所示：

000000000000000100000000000003

我使用系统调用x86而不是64位读取它们，并将其存储在2个缓冲区中。当我想从它们中提取一个字节时，我会：

movl $15, %eax
addl $NUMBER1, %eax
movzbl (%eax), %eax

现在我有了这个数字的最后一个字节，在%eax索引中，当然从零开始。然后我选择： btl$0，%eax

所以在这种情况下应该很容易。我在eax中存储了一个字节1。当然，我从右边检查它的第一位，所以32位1=00000000000000000000000000000000 1，所以我应该在进位标志中得到1。我用jc carry_1检查它-当然，它是有效的。但后来，我试着检查其他东西。因为很明显，我不应该比较从最低有效数字开始的两个数字，我应该从左边开始。所以我选择btl$31，%eax，是的，当然在这种情况下，我在进位标志中得到0。所以我只是想检查一下我的%eax的外观，以确保我没有意外得到任何东西

所以在gdb中，我启动了我的可执行文件。我和movzbl打过电话，我已经打过了。现在是检查的时候了：

打印/电汇$eax。我想我会得到：00000000000000000000000000000001，但是没有。我看到的是：

33      movzbl (%eax), %eax
(gdb) s
34      btl $31, %eax
(gdb) print /t $eax
$1 = 110001

那为什么是110001？当我检查3的时候，它是110011，所以这个结尾是正确的，但是在Begging的那11又是什么呢？我的意思是它肯定不是两个补码的符号位，因为只有一个+它将是零，因为我的数字是正的。你知道是什么吗

我使用as-32和ld-melf_i1386在Manjaro 64位上编译它

那为什么是110001

---

您忽略了代码的重要部分，例如从文本文件中读取数字的部分。但很有可能你只是读了所有的字符，然后把它们存储在某个地方。字符“1”的ASCII码是49，在二进制中/t开关给出的二进制码是110001。因此，如果内存中的字符是“1”，则此输出完全是预期的。

16字节的数字看起来更像32字节长的ASCII字符串，可能表示十六进制编码，如12AB，在正确转换后表示为值0x12AB。当您必须比较它们时，您可以将它们作为字符串进行比较，无需将它们转换为数字，ASCII字符保留了数值的所有重要特征，如“0”<“1”<“9”<“A”<“F”，因此如果两个数字都有前导零，32个字符长，然后，只需逐个字符进行比较，就可以知道哪个字符以无符号方式小于/大于/等于哪个字符。不需要逐位比较，dword逐dword cmp是可以的。。。为了简化，我将仅比较8个字符的长字符串01234567与0123456A->当加载两个字符串的前4个字节时，将得到值0x33323130，cmp将以ZF=1结束。最后4个字节将是0x37363534 vs 0x41363534，因此cmp会意外地告诉第二个num高于正确值。我很好地发现自己在撒谎，因为字符串是big-endian和x86-little-endian，0100对0010将以0x30303130对0x30313030结束=>上面的第二个=>错误答案。因此，在ASCII中，必须逐字符cmp。德沃德用数字值工作。我刚刚注意到我是弱智。你是完全正确的，我必须这么做，我来这里是想说我很愚蠢，但是你更快了：谢谢