5、内存透视：x命令与内存布局分析

调试嵌入式程序，说白了就是在跟内存打交道。

指针飞了、栈溢出了、全局变量被意外修改了……这些故障，十有八九都跟内存有关。我做了十几年嵌入式开发，最深的体会就是：谁掌握了内存视角，谁就掌握了调试的主动权。

这一章，我们就来聊聊GDB里那个最强大的内存查看工具——x命令。以及，怎么用它来分析内存布局。

5.1 x命令：你的内存显微镜

x命令的全称是examine，意思是“检查”。它的基本用法很简单：

(gdb) x/<nfu> <address>

这里的n、f、u三个参数，分别代表：

  • n：要显示多少个单元（重复次数）
  • f：显示格式（x十六进制、d十进制、c字符、s字符串、i指令）
  • u：单元大小（b字节、h半字、w字、g双字）

举个例子：

(gdb) x/10xw 0x20000000
0x20000000: 0x12345678 0x9abcdef0 0xdeadbeef 0xcafebabe
0x20000010: 0x00000001 0x00000002 0x00000003 0x00000004
0x20000020: 0x00000005 0x00000006

这条命令的意思是：从地址0x20000000开始，以十六进制格式显示10个字（4字节）的内容。

我的习惯：调试时我几乎只用x/10xw和x/20xb这两种组合。前者看32位数据，后者看字节序列。够用了。

5.2 常见格式组合速查

命令 含义 适用场景
x/10xb 10个字节，十六进制 看缓冲区、数组原始内容
x/10xw 10个字，十六进制 看寄存器、指针、32位变量
x/10s 10个字符串 看字符串表、消息队列内容
x/10i 10条指令 反汇编，看当前执行到哪了
x/10fd 10个浮点数 看浮点数组
注意：地址一定要对齐。如果你要查看一个uint32_t变量，地址必须是4字节对齐的。我曾经在调试时因为地址写错了，看了半天全是乱码，最后发现是地址少写了一个0……嗯，这种低级错误，犯过一次就记住了。

5.3 实战：用x命令分析内存布局

光说不练假把式。我们来看一个真实场景。

假设你有这样一个结构体：

struct sensor_data {
    uint32_t timestamp;   // 4字节
    uint16_t temperature; // 2字节
    uint16_t humidity;    // 2字节
    uint8_t  status;      // 1字节
    // 这里会有3字节填充
    uint32_t checksum;    // 4字节
};

你定义了一个全局变量：

struct sensor_data g_sensor;

现在，你想看看它在内存里到底是怎么排列的。用x命令：

(gdb) p &g_sensor
$1 = (struct sensor_data *) 0x20000100

(gdb) x/16xb 0x20000100
0x20000100: 0x5a 0x6b 0x7c 0x8d  // timestamp = 0x8d7c6b5a
0x20000104: 0x1e 0x2f            // temperature = 0x2f1e
0x20000106: 0x3a 0x4b            // humidity = 0x4b3a
0x20000108: 0x01                 // status = 1
0x20000109: 0x00 0x00 0x00       // 填充字节（全是0）
0x2000010c: 0x12 0x34 0x56 0x78  // checksum = 0x78563412

看到了吗？填充字节清清楚楚地摆在那里。这就是内存对齐的真相。

关键洞察：结构体的大小不是成员大小的简单相加。因为对齐的存在，编译器会在成员之间插入填充字节。用x命令一看，什么都藏不住。

5.4 进阶：用x命令定位内存越界

内存越界是嵌入式开发里最头疼的问题之一。我遇到过最典型的一次：一个数组写越界了，把相邻的变量给覆盖了。症状很诡异——某个全局变量每隔一段时间就会变成0xdeadbeef。

排查步骤是这样的：

  1. 先用print &可疑变量拿到地址
  2. 用x/32xb查看周围内存
  3. 在可疑操作前后分别查看，对比变化

举个例子：

// 假设 buf 和 flag 是相邻的全局变量
uint8_t buf[16];
uint32_t flag = 0;

// 某处代码有bug，写越界了
void buggy_func(void) {
    for (int i = 0; i <= 16; i++) {  // 注意：i <= 16，越界了！
        buf[i] = 0xff;
    }
}

调试时：

(gdb) p &buf
$1 = (uint8_t (*)[16]) 0x20000200

(gdb) p &flag
$2 = (uint32_t *) 0x20000210

(gdb) x/20xb 0x20000200
0x20000200: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20000208: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x20000210: 0x00 0x00 0x00 0x00  // flag 还是0

// 执行buggy_func()后再次查看
(gdb) x/20xb 0x20000200
0x20000200: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x20000208: 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0x20000210: 0xff 0xff 0xff 0xff  // flag 被覆盖成了0xffffffff！

证据确凿。buf[16]写到了flag的地址上。

避坑指南：我曾经在一个项目里，因为结构体末尾的填充字节被某个驱动库错误地写入了数据，导致整个系统随机崩溃。用x/64xb扫了一遍内存，才发现填充区域里出现了不该有的值。从那以后，我养成了一个习惯——所有结构体都手动用sizeof()确认大小，再用x命令看一眼实际布局。

5.5 内存布局全景图

为了让你更直观地理解内存布局，我画了一张图。这张图展示了一个典型的嵌入式程序在RAM中的分布情况。

嵌入式程序 RAM 内存布局示意图 栈区（Stack） 局部变量、函数调用帧、返回地址 向下增长 堆区（Heap） malloc/free 动态分配的内存 向上增长 BSS段（未初始化全局/静态变量） 数据段（已初始化全局/静态变量） 只读数据段（字符串常量、const变量） 高地址 低地址

这张图里，从上到下依次是：

  • 栈区：存放局部变量、函数参数、返回地址。向下增长。
  • 堆区：动态分配的内存。向上增长。
  • BSS段：未初始化的全局变量和静态变量。上电时清零。
  • 数据段：已初始化的全局变量和静态变量。
  • 只读数据段：字符串常量、const变量。

为什么这张图重要？因为很多内存问题，本质上就是不同区域之间的“越界碰撞”。比如栈向下增长太多，撞到了堆；或者堆向上增长太多，覆盖了BSS段。用x命令查看边界地址，往往能第一时间发现问题。

5.6 实用技巧：快速定位变量地址

最后，分享几个我常用的组合技：

  1. 查看指针指向的内容：x/10xw *指针变量
  2. 查看数组全部内容：x/数组长度xb 数组名
  3. 查看结构体成员偏移：print &((struct type *)0)->member，然后用x验证
  4. 对比修改前后：在可疑代码前后各执行一次x，用diff工具对比输出

一句话总结：x命令就是你的内存CT扫描仪。学会用它，你就能看到程序运行时内存里的每一个字节。很多看似诡异的问题，在内存的“原图”面前，都会原形毕露。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →