18. 结构体与调试技巧：GDB打印结构体、内存dump分析、常见错误排查

调试结构体相关的代码，说实话，是很多C语言工程师的噩梦。我自己刚入行那会儿，就因为在结构体指针上栽过跟头，整整调了两天。后来我总结了一句话：结构体调试，本质上是内存布局的调试。你只要把内存看透了，问题就解决了一半。

这一章，我带你从三个角度切入：GDB怎么用、内存dump怎么看、常见错误怎么防。嗯，都是实战中摸爬滚打出来的经验。

18.1 GDB打印结构体：从入门到熟练

GDB是嵌入式调试的标配。我个人习惯，只要代码里用了结构体，调试时第一件事就是打印它的内存地址和成员值。

18.1.1 基本打印命令

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

typedef struct {
    uint8_t id;
    uint16_t value;
    char name[16];
    float ratio;
} SensorData;

SensorData sensor = {0x01, 1000, "temp", 3.14f};

在GDB里，你可以这样打印：

(gdb) p sensor
$1 = {id = 0x1 '\001', value = 1000, name = "temp", '\000' <repeats 11 times>, ratio = 3.1400001}

嗯，这里有个细节：GDB会显示所有成员，包括数组里未初始化的部分。如果你只想看某个成员：

(gdb) p sensor.value
$2 = 1000
(gdb) p sensor.name
$3 = "temp"

18.1.2 打印结构体指针

指针的情况更常见。我遇到过很多新手，打印指针时忘了解引用：

SensorData *pSensor = &sensor;

// 错误做法
(gdb) p pSensor
$4 = (SensorData *) 0x7fffffffe010

// 正确做法
(gdb) p *pSensor
$5 = {id = 0x1 '\001', value = 1000, name = "temp", ...}

或者用GDB的简洁语法：

(gdb) p pSensor->value
$6 = 1000

18.1.3 格式化打印内存

有时候，结构体成员的值看起来不对，但GDB打印出来又是正常的。这时候我建议你直接看内存：

(gdb) x/16xb &sensor
0x7fffffffe010: 0x01 0x00 0x00 0xe8 0x03 0x00 0x00 0x00
0x7fffffffe018: 0x74 0x65 0x6d 0x70 0x00 0x00 0x00 0x00

你看，0xe8 0x03 就是小端模式的1000（0x03e8）。0x74 0x65 0x6d 0x70 就是"temp"的ASCII码。内存不会骗人，对吧？

18.2 内存dump分析：把结构体当字节看

嵌入式开发中，经常遇到死机、HardFault这类问题。这时候GDB可能已经连不上了，只能靠内存dump（也叫core dump）来分析。说白了，就是把RAM里的数据导出来，然后人工解析。

18.2.1 什么时候需要内存dump？

• 程序跑飞了，GDB断不下来
• 结构体成员的值莫名其妙被篡改
• 怀疑栈溢出或堆内存越界
• 通信协议解析出错，想看看原始数据

我曾经在一个电机控制项目里，发现电流采样值偶尔跳变。用GDB单步跑没问题，但全速运行时就会出问题。最后我dump了ADC缓冲区，才发现是DMA传输时地址没对齐，导致数据错位了。

18.2.2 如何手动解析dump数据

假设你dump了一段内存，起始地址是0x20000100，内容是：

0x20000100: 0x01 0x02 0x00 0x00 0x41 0x42 0x43 0x44
0x20000108: 0x00 0x00 0x80 0x3f 0x00 0x00 0x00 0x00

对应的结构体定义是：

typedef struct {
    uint8_t  header;    // 1字节
    uint8_t  flags;     // 1字节
    uint16_t length;    // 2字节
    char     data[4];   // 4字节
    float    value;     // 4字节
} Packet;

我们来手动解析：

• header = 0x01
• flags = 0x02
• length = 0x0002（小端模式，低字节在前）
• data = "ABCD"（0x41='A', 0x42='B', ...）
• value = 0x3f800000，这是单精度浮点数的1.0

你看，只要知道结构体的内存布局，手动解析其实不难。关键是你要清楚对齐规则和字节序。

18.3 常见错误排查：我踩过的坑

下面这几个错误，我敢说每个嵌入式工程师都遇到过。我把它们列出来，你对照着检查自己的代码。

18.3.1 指针未初始化

// 错误示例
SensorData *pSensor;
pSensor->value = 100;  // 野指针！程序必崩

// 正确做法
SensorData sensor;
SensorData *pSensor = &sensor;
pSensor->value = 100;

嗯，这个错误太经典了。我见过有人调试了一整天，最后发现是malloc之后忘了检查返回值。

18.3.2 结构体赋值时的浅拷贝问题

typedef struct {
    char *name;  // 指针成员
    int   id;
} Person;

Person p1 = {"Alice", 1};
Person p2 = p1;  // 浅拷贝！p2.name 和 p1.name 指向同一块内存

free(p1.name);   // 释放了p1的name
// 此时p2.name变成了野指针

我曾经在一个通信协议栈里犯过这个错。两个结构体共享了同一个缓冲区，结果一个释放了，另一个还在用。排查起来特别痛苦，因为崩溃的位置和出错的位置往往不在同一个函数里。

18.3.3 字节对齐导致的隐式bug

typedef struct {
    uint8_t  a;  // 1字节
    uint32_t b;  // 4字节
    uint8_t  c;  // 1字节
} Misaligned;

// 实际大小：12字节（而不是1+4+1=6）
// 因为b需要4字节对齐，a后面填充了3个字节
// c后面又填充了3个字节

你想想看，如果你把这个结构体通过串口发送出去，接收方按1+4+1来解析，那数据就全乱了。我建议你在定义结构体时，把大尺寸成员放在前面，小尺寸放在后面，或者手动指定__attribute__((packed))。

18.3.4 结构体作为函数参数时的拷贝开销

// 低效做法：整个结构体拷贝
void process_data(SensorData data) {
    // ...
}

// 高效做法：传指针
void process_data(SensorData *data) {
    // ...
}

如果结构体很大（比如几百字节），传值会导致栈空间暴涨。我在一个RTOS项目里见过，因为传结构体导致任务栈溢出，系统反复重启。排查了三天才发现是这个问题。

18.4 知识体系总览

下面这张图，我把本章的核心知识点串起来了。你可以把它当作调试时的检查清单。

18.5 调试流程总结

最后，我整理了一个简单的调试流程，你可以贴在工位上：

1. 确认结构体定义：用sizeof和offsetof宏检查大小和偏移量
2. 打印关键成员：用GDB的p命令，或者直接看内存x
3. 检查指针有效性：确保指针不为NULL，且指向的内存已初始化
4. 验证字节序和对齐：跨平台通信时尤其要注意
5. 排查越界和拷贝：用内存dump对比预期值和实际值

嗯，调试结构体其实没那么玄乎。你只要记住：结构体就是一块有规则的内存。把内存看懂了，什么问题都能找到根因。

---