GDB 的 p str 默认只显示前 256 个字符，因 print elements 全局限制为 256；完整显示可用 x/s str 或 set print elements 0。
默认用 p 打印字符串会截断，完整内容得换方法或调配置。
为什么 p str 只显示前 256 个字符？
GDB 默认对字符串输出设了长度上限，防止调试时刷屏。这个限制由 print elements 控制，初始值是 256。
- 执行
p str时，GDB 按照变量类型自动识别为字符串，并受该全局限制影响 - 即使
str实际指向 10KB 的日志缓冲区，你也只看到开头部分 - 这不是 bug，是设计行为；但调试日志、JSON 或协议载荷时会直接失效
完整显示字符串的两种可靠方式
推荐优先用 x/s，它绕过打印限制，直读内存；若需格式化上下文（比如带引号、转义），再配 set print。
-
x/s &str或x/s str：直接以 C 字符串方式解析并显示，遇到第一个\0自动停止，不依赖print elements -
set print elements 0：关闭p命令的字符数限制，之后所有p str都会完整输出（注意：也会影响数组、结构体等其他类型显示长度） - 临时改限：比如只要看 1024 字符，运行
set print elements 1024即可，无需永久生效
x/s 和 p/s 的关键区别
别混淆这两个命令——它们底层机制不同，适用场景也不同。
-
x/s &str：从地址开始扫描内存，按字节找\0，纯内存视角，适合原始指针、堆上字符串、未初始化缓冲区 -
p/s str：先求值str（比如解引用指针），再按字符串格式打印，受print elements和print null-stop影响 - 如果
str是char buf[512]这种栈数组，x/s buf更稳；如果是char *str = malloc(...)，两者都行，但x/s str不依赖符号表完整性 -
x/s不处理宽字符（wchar_t），要查宽字符串得用x/100cw &wstr类似方式
容易被忽略的细节
字符串内容“看似完整”，其实可能早被截断或污染，尤其在堆/栈边界附近。
- 用
x/s后发现结尾乱码？大概率是内存越界写入导致\0被覆盖，这时应配合x/32xb &str查看原始字节验证 -
set print null-stop on能让p在遇到\0时提前终止，避免打印一堆\000填充字节（常见于固定大小数组） - 如果字符串含不可见控制字符（如
\r、\b），x/s会原样显示，而p/s可能做转义；需要确认原始二进制内容时，x/16cb &str更直观
