gdb断点命中次数（hit列）是判断函数是否被调用的唯一可靠指标，需设断点后运行程序（run/continue）再执行info breakpoints查看；hit为0可能因未运行、库未加载、符号不匹配或断点位置错误。
直接看断点命中次数，比加日志快得多，也比手动单步靠谱。
用 break 打函数名后立刻 info breakpoints
函数断点设上不等于它被调用了——GDB 只记录「命中断点」的次数，不是「函数声明存在」或「符号被加载」。所以关键动作是：设完断点后必须运行程序（run 或 continue），再查命中数。
-
break printNum设断点，info breakpoints显示What列里带printNum，但Disp是keep、Enb是y，此时还看不出是否调用过 - 执行
run后程序退出（或中断），再输一遍info breakpoints，看Hit列：0 表示没调用，≥1 表示调用了 - 如果函数在共享库中且尚未加载，
break会成功但Hit始终为 0——先run让动态库加载，再info breakpoints
多个同名函数时，info functions 配合 break *addr
比如 printNum 在 libutils.so 和主程序里各有一个，break printNum 默认只打第一个，你看到 Hit 为 0，可能只是打错了那个。
- 先
info functions printNum列出所有匹配符号，注意看文件路径和地址 - 挑准你要监控的那个，比如输出里有
File utils.c:12和File main.c:8，用break *0x7ffff7bc12a0（地址替换成实际值）精准打断点 - 否则
Hit为 0 可能只是函数根本没走到你打的那个重载版本
函数调用极快或只调一次，别依赖 continue 看停不停
有些函数调用完立刻返回，你设了断点但没看到 GDB 暂停，容易误判为「没调用」——其实它调了、断点了、又自动 continue 了（比如被 ignore 过或条件不满足）。
- 设完断点后不要只等暂停，务必用
info breakpoints查Hit数，这是唯一可靠指标 - 如果函数在循环里高频调用，
Hit会快速上涨；如果只调一次但你漏看了暂停瞬间，Hit仍会是 1 - 避免用
step跟进函数再出来——万一它内联了或被优化掉，step根本不进，但break+Hit依然有效
真正容易被忽略的是：断点是否打在了最终链接进进程的那个符号上。动态库延迟加载、函数内联、LTO 优化都可能导致 break 函数名 看似成功，实则断点挂在了死符号上——所以每次怀疑没调用，先确认 run 过、info sharedlibrary 看库已加载、info functions 确认符号存在，再信 Hit 字段。
