最直接可靠的方式是ptype /o struct_name，它按内存布局顺序列出各字段偏移与大小，含嵌套结构体、位域及填充字节，需在GDB已加载符号上下文中执行。
用 ptype /o 直接看结构体字段偏移
最直接、最可靠的方式就是 ptype /o struct_name。它会按内存布局顺序列出每个字段的起始偏移（字节）和大小，包括嵌套结构体、位域、填充字节（padding）等细节。
注意：必须在 GDB 已加载符号的上下文中执行，比如已 file vmlinux 或已运行到断点处且目标结构体类型可见。
-
/o是关键参数，缺了就只显示类型定义，不显示偏移 - 输出中类似
/* 0 | 4 */表示该字段从结构体起始地址偏移 0 字节，占 4 字节 - 若看到
XXX 3-byte padding这类注释，说明编译器插入了填充，实际偏移不能靠手动累加字段大小估算 - 对内核结构体（如
struct amba_device），ptype /o能反映当前内核配置下的真实布局，比查源码更准
没有符号时用 p &((struct T*)0)->f 算单个字段偏移
当 GDB 没加载调试符号（比如只有 stripped 的 vmlinux），ptype 会失败，但你仍可借助 C 表达式强制计算——原理和内核 container_of 宏一致。
例如查 struct worker 中 flags 成员的偏移：
(gdb) p &((struct worker*)0)->flags $1 = (unsigned int *) 0x68
结果 0x68 就是偏移值（十进制 104）。这个技巧依赖编译器对空指针解引用的容忍（GDB 内部不真访问内存），所以安全。
- 仅适用于字段名已知、结构体名能被 GDB 识别的情况（即使没完整符号，部分类型名可能残留）
- 不能用于柔性数组（flexible array member）或含变长成员的结构体
- 如果报错
Cannot take address of bit-field，说明该字段是位域（bit-field），得换其他方式（如反汇编或查offsetof定义）
确认结构体大小和字段对齐是否影响偏移
偏移不是固定值，它受编译器对齐规则、__attribute__((packed))、以及内核配置宏（如 CONFIG_DEBUG_SPINLOCK）直接影响。同一个结构体，在不同内核版本或配置下，偏移可能差几个字节。
- 用
p sizeof(struct xxx)验证当前镜像中该结构体的实际大小，和ptype /o的total size行对比 - 若发现某字段偏移异常大，大概率是前面字段触发了对齐（如
u64成员要求 8 字节对齐，前面若有 3 字节字段，就会插 5 字节 padding） - 内核中常见陷阱：
struct device的kobj成员在某些配置下会被条件编译掉，导致后续所有字段偏移整体前移
容易忽略的坑：位域、匿名 union、嵌套结构体的偏移嵌套
位域（如 unsigned int state_initialized:1;）在 ptype /o 输出里不会单独列偏移，而是和它所属的整数字段共用起始地址；匿名 union 的字段则共享同一偏移；嵌套结构体的偏移是“相对外层结构体起始”的，不是相对于其自身。
- 查
struct amba_device里device.kobj.entry.next的最终偏移，要逐层叠加：device偏移 +kobj偏移 +entry偏移 +next偏移 - 用
ptype /o struct kobject单独查内层结构，再结合外层输出里的嵌套位置，才能准确定位深层字段 - GDB 不支持直接写
&((struct amba_device*)0)->device.kobj.entry.next这种多级路径表达式，会报错，必须分步或靠ptype /o推导
真正卡住调试的，往往不是不知道命令，而是看到 ptype /o 里一堆 XXX padding 和嵌套缩进时没意识到：那个看似“多余”的偏移跳变，恰恰是 panic 地址算错的关键。
