GDB 是否检查命令反向字节?
Does the GDB examine command reverse bytes?
gdb 在打印多个字块(4 个字节)时是否颠倒字节顺序?
如果是这样,那为什么呢?这与程序读取内存的方式有关系吗?
这里有一个示例代码来演示颠倒顺序
的意思
// test.c
#include <stdio.h>
int main(int argc, char *argv[])
{
int large = 33825; // 1000 0100 0010 0001
int zero = 0; // 0000 0000 0000 0000
int ten = 10; // 0000 0000 0000 1010
printf("GDB test program\n");
return 0;
}
用 gdb 编译 & 运行 程序:
$ gcc -z execstack -g -fno-stack-protector test.c -o test
$ gdb test
(gdb) break 9
Breakpoint 1 at 0x8048441: file test.c, line 9.
(gdb) run
Breakpoint 1, main (argc=1, argv=0xbfffeff4) at test.c:9
9 return 0;
(gdb) # get the address of the ten variable (which has the smallest memory address location)
(gdb) print &ten
= (int *) 0xbfffef34
(gdb) # print the first byte of the ten variable
(gdb) x /1tb 0xbfffef34
0xbfffef34: 0000 1010
(gdb) # print the entire memory (4 bytes) allocated for the ten variable (0xbfffef34 - 0xbfffef38)
(gdb) x /1tw 0xbfffef34
0xbfffef34: 0000 0000 0000 0000 0000 0000 0000 1010
(gdb) # Why is "0000 0000" the first octet instead of "0000 1010"
(gdb) # It seems like the print order of the bytes are reversed
(gdb) # Another example
(gdb) # print the entire memory (4 bytes) allocated for the large variable (0xbfffef3c - 0xbfffef3f)
(gdb) x /1tw 0xbfffef3c
0xbfffef3c: 0000 0000 0000 0000 1000 0100 0010 0001
(gdb) x /1tb 0xbfffef3c
0xbfffef3c: 0010 0001
(gdb) x /1tb 0xbfffef3d
0xbfffef3d: 1000 0100
(gdb) x /1tb 0xbfffef3e
0xbfffef3e: 0000 0000
(gdb) x /1tb 0xbfffef3f
0xbfffef3f: 0000 0000
当我打印整个变量时,它读取我通常读取二进制的方式(左边最重要的八位字节)
当我打印同一个变量的第一个八位位组时,它显示最低有效的八位位组。
GDB 是否重新排列八位字节的顺序以使其更具可读性?这与计算机读取内存的方式有什么关系吗?
print
以人类期望的方式打印变量(作为整数)。
examine
将它们打印为内存中的字节,而不修改它们以补偿计算机使用的字节顺序。
gdb 在打印多个字块(4 个字节)时是否颠倒字节顺序? 如果是这样,那为什么呢?这与程序读取内存的方式有关系吗?
这里有一个示例代码来演示颠倒顺序
的意思// test.c
#include <stdio.h>
int main(int argc, char *argv[])
{
int large = 33825; // 1000 0100 0010 0001
int zero = 0; // 0000 0000 0000 0000
int ten = 10; // 0000 0000 0000 1010
printf("GDB test program\n");
return 0;
}
用 gdb 编译 & 运行 程序:
$ gcc -z execstack -g -fno-stack-protector test.c -o test
$ gdb test
(gdb) break 9
Breakpoint 1 at 0x8048441: file test.c, line 9.
(gdb) run
Breakpoint 1, main (argc=1, argv=0xbfffeff4) at test.c:9
9 return 0;
(gdb) # get the address of the ten variable (which has the smallest memory address location)
(gdb) print &ten
= (int *) 0xbfffef34
(gdb) # print the first byte of the ten variable
(gdb) x /1tb 0xbfffef34
0xbfffef34: 0000 1010
(gdb) # print the entire memory (4 bytes) allocated for the ten variable (0xbfffef34 - 0xbfffef38)
(gdb) x /1tw 0xbfffef34
0xbfffef34: 0000 0000 0000 0000 0000 0000 0000 1010
(gdb) # Why is "0000 0000" the first octet instead of "0000 1010"
(gdb) # It seems like the print order of the bytes are reversed
(gdb) # Another example
(gdb) # print the entire memory (4 bytes) allocated for the large variable (0xbfffef3c - 0xbfffef3f)
(gdb) x /1tw 0xbfffef3c
0xbfffef3c: 0000 0000 0000 0000 1000 0100 0010 0001
(gdb) x /1tb 0xbfffef3c
0xbfffef3c: 0010 0001
(gdb) x /1tb 0xbfffef3d
0xbfffef3d: 1000 0100
(gdb) x /1tb 0xbfffef3e
0xbfffef3e: 0000 0000
(gdb) x /1tb 0xbfffef3f
0xbfffef3f: 0000 0000
当我打印整个变量时,它读取我通常读取二进制的方式(左边最重要的八位字节)
当我打印同一个变量的第一个八位位组时,它显示最低有效的八位位组。
GDB 是否重新排列八位字节的顺序以使其更具可读性?这与计算机读取内存的方式有什么关系吗?
print
以人类期望的方式打印变量(作为整数)。
examine
将它们打印为内存中的字节,而不修改它们以补偿计算机使用的字节顺序。