x命令是gdb中专用于查看原始内存内容的指令，不经过类型解析、不受作用域或优化影响；其格式为x/nfu address，其中n为单元数量、f为显示格式（如x为十六进制）、u为单元大小（b/h/w/g），默认n=1、u=w；常用组合如x/16xb查看16个独立字节，x/4xw查看4个4字节整数（小端序下字节顺序反转）；print /x输出变量逻辑值，x输出地址真实字节，二者本质不同。
x 命令是唯一可靠的方式，x 不是 print 的替代品，它专为原始内存设计，不经过类型解析，也不会受变量作用域或优化干扰。
用 x/xb、x/xh、x/xw 查看字节/半字/字的十六进制值
十六进制查看必须显式指定格式 x 和单位 u，不能只写 x 或漏掉单位。常见组合有：
-
x/16xb &buf：查看buf起始地址后 16 个字节，每个字节独立显示为两位十六进制（如0x3a） -
x/8xh &buf：查看 8 个半字（每项 2 字节），结果是 4 位十六进制（如0xabcd） -
x/4xw &buf：查看 4 个字（每项 4 字节），结果是 8 位十六进制（如0x12345678），注意小端序下字节顺序会反转
省略数量时默认为 1，省略单位时默认为 w（4 字节），容易误读成“一个整数”而非“一个内存单元”。
别把 print /x 当作内存查看工具
print /x var 输出的是变量的**值**（经类型解释后的逻辑值），而 x 输出的是**地址上实际存储的原始字节**。两者在以下场景结果完全不同：
- 对指针变量
p执行print /x p→ 显示指针本身的地址值（如0x7fffffffe010） - 执行
x/4xb p→ 显示p指向的那 4 个字节内容（如0x61 0x62 0x63 0x00） - 结构体成员对齐填充区域、未初始化内存、union 重叠字段等，只有
x能暴露真实布局
VS Code 调试控制台里执行 x 要加 -exec
在 VS Code 的“调试控制台”中直接输 x/10xb buf 会报错 Undefined command: "x"，因为该面板默认不识别 GDB 原生命令。必须前置 -exec：
- 正确：
-exec x/10xb buf - 错误：
x/10xb buf（提示命令未定义） - 监视窗口中想看十六进制值，不能用
x，而是写buf,h—— 这是 VS Code 自己的语法，仅适用于变量表达式，不支持任意地址或内存范围
回车重复和 sticky formatting 容易导致误判
执行一次 x/8xb &data 后按回车，GDB 会从 &data + 8 继续显示下 8 字节；再按回车继续 +8 —— 这很高效，但也容易忘记当前看到的是哪段地址。更隐蔽的问题是 sticky formatting：
- 先执行
x/4xw &s，再执行x/8（没带任何参数）→ GDB 自动沿用xw，即以 4 字节为单位显示 8 个整数，不是你想要的 8 字节 - 想切回字节视图，必须显式写
x/8xb，不能依赖回车或省略 - 调试时建议在每次关键查看后手动执行
x/1xb &addr重置单位，避免后续命令被静默影响
真正难的不是记参数，而是意识到：你看到的每一个字节，都可能被对齐、填充、大小端、未定义行为悄悄改写过 —— x 只负责呈现，解释得靠你自己。
