next不会跳过printf等系统调用，因为它按源码行执行，而printf调用涉及PLT/GOT跳转并进入libc；若要“跳过”，需移除调试符号或用finish/set skip-solib-paths。
不能真正“跳过”系统库函数的执行，但可以避免单步进入、不被其断点干扰、或快速跳出——关键在控制断点和步进行为。
为什么 next 不会跳过 printf / malloc 等系统调用
因为 next 是按源码行步进，而你看到的 printf("hello") 这一行，在编译后实际包含：参数压栈 → 调用 PLT stub → 间接跳转到 libc 中的实现。这些都不在你的源码里。next 执行完这一行，就直接跑进 libc 了；它不会“自动跳过外部函数”，除非你没编译调试符号（-g）且 libc 没加载符号——但这只是看不到，不是没进。
- 如果你用
gcc -g编译，又装了libc6-dbg（Debian/Ubuntu）或glibc-debuginfo（RHEL/CentOS），GDB 就能显示printf内部汇编甚至 C 源码，next自然会进去 - 即使没装 debuginfo，只要符号表存在（默认有），
next仍会单步执行 PLT 和 GOT 跳转逻辑，你看到的是汇编指令，不是“跳过” - 想让
next表现得像“跳过”，唯一可靠方式是：确保 GDB 找不到系统库的调试信息（删 debuginfo 包 + 不加载/usr/lib/debug）
如何让 GDB 不进入 system 函数（如 printf、malloc、open）
这不是靠 magic 命令，而是组合使用断点控制与步进策略：
- 用
next（不是step）——它本意就是“步过函数调用”，对无调试符号的函数会直接运行完并停在下一行 - 提前禁用所有可能命中系统函数的断点：
disable或删掉用b printf这类设的函数级断点 - 检查是否误启用了
set step-mode on（它会让next在无符号时也尝试步入）；恢复默认：set step-mode off - 若已卡在
printf汇编里，别反复next，直接用finish跳出当前函数（哪怕它是 libc 的） - 更彻底：用
set skip-solib-paths /usr/lib/x86_64-linux-gnu/libc.so.6（路径按实际调整），GDB 会跳过匹配路径的共享库中的所有断点和单步
什么时候必须面对系统函数？哪些情况“跳过”会失效
以下场景中，所谓“跳过”要么不可行，要么掩盖真实问题：
- 调试
malloc失败或free崩溃时，你必须进 libc —— 因为堆管理逻辑就在那里，next再怎么跳也绕不开 - 用
catch syscall捕获brk或mmap时，GDB 一定会停在内核入口，这不是“进入函数”，而是系统调用拦截机制生效 - 静态链接（
-static）后，printf代码直接打进你的可执行文件，next必然步入——此时跳过唯一办法是删掉对应行的断点、或用jump绕开调用指令（危险，易破坏状态） -
set scheduler-locking on对单线程无效，但它会影响多线程下系统调用的可观测性：比如一个线程卡在read阻塞，另一个线程的next可能被调度锁拖慢
最常被忽略的一点：GDB 本身不决定“是否执行”某个函数，只决定“是否停在那里”。printf 总会执行，你控制的只是“要不要看它怎么执行”。真要跳过逻辑，得改代码（比如条件编译屏蔽日志）、或用 return 强制提前返回（仅限你自己的函数）。对系统函数，return 会破坏栈平衡，绝对不要用。
