直接运行 ltrace ./my_program 可跟踪动态链接程序的库函数调用，显示如 printf("hello\n") = 13 的输出；需确保程序为动态链接，不支持静态链接或 stripped 二进制的符号解析。
ltrace 跟踪库函数调用的基本命令怎么写
直接运行 ltrace ./my_program 就能开始跟踪——它会拦截所有动态链接库（如 libc、libm）中被调用的函数，显示形如 printf("hello\n") = 13 的输出。这个命令默认不捕获系统调用，只看用户态库函数。
注意：被跟踪程序必须是动态链接的（file my_program 输出含 “dynamically linked”）。静态链接或 stripped 二进制可能看不到符号名，返回值仍可见但函数名显示为 0x7f...@plt。
- 如果程序启动即退出，加
-t或-T看时间戳/耗时，避免漏掉一闪而过的调用 - 若提示
Could not open library ... No such file or directory，说明运行时找不到依赖库，先用ldd ./my_program检查路径和缺失项 - 不要对 setuid 程序（如
sudo）直接使用 ltrace，默认被内核禁止；需临时关闭kernel.yama.ptrace_scope或换普通用户测试
怎么只看 malloc、printf 这类关键函数的调用
用 -e 选项过滤，比如 ltrace -e "malloc,free,printf" ./my_program。它支持简单通配符：-e "open*" 匹配 open、openat，但不支持正则；多个函数用英文逗号分隔，不能有空格。
-
-e "libc.so.6:malloc"可限定来自特定库的函数，避免误匹配同名符号（如自定义malloc） - 若目标函数在非标准库（如
librd3.so），需确保该库路径已加入LD_LIBRARY_PATH，否则 ltrace 找不到符号表，可能只显示地址 - 过滤后仍看到大量无关调用？可能是子进程触发的——加
-f才能完整覆盖 fork 出的子进程
如何统计哪些库函数最耗时或调用最多
加 -c 选项，例如 ltrace -c ./my_program，程序退出后会输出汇总表，包含每个函数的调用次数、总耗时、平均耗时、占比等。
这个统计基于实际执行时间，不是 CPU 周期，所以对 I/O 密集型库函数（如 fread、regexec）特别有用——它们可能比系统调用还慢。
-
-T和-c不冲突，可以同时用：ltrace -c -T ./my_program，既看单次耗时，又得汇总 - 注意
-c会显著拖慢执行速度（所有调用都插桩计时），生产环境慎用；调试性能瓶颈时优先考虑perf record -e 'cycles,instructions' --call-graph dwarf - 如果某函数在统计里占比极高但逻辑简单（如
strlen），很可能是传入了超长字符串或陷入重复扫描，要回头检查上游数据
为什么 attach 到运行进程（-p）经常失败或没输出
常见原因是目标进程已进入“不可中断睡眠”（D 状态），或刚完成库调用、正处在纯计算循环中。ltrace 依赖 PLT/GOT 动态链接机制下函数入口的可拦截性，attach 时机不对就捕获不到。
- attach 前先用
ps -o pid,comm,state -p PID确认进程状态是R或S，不是D - 若进程由 systemd 启动，可能受
RestrictSUIDSGID=yes或ProtectHome=yes限制，导致 ltrace 无法注入；改用systemctl set-property --runtime myservice MemoryLimit=8G临时放宽再试 - attach 后没输出？试试加
-S同时跟踪系统调用，看是否卡在read或epoll_wait上——那说明它根本没调库函数，只是在等事件
真正难的是区分“没调用”和“调用了但没捕获到”：PLT 表可能被优化掉（如 -fno-plt 编译）、函数被内联、或用了 dlsym + 函数指针间接调用——这些情况 ltrace 都看不见，得切到 gdb 或 perf probe。
