如何解决如何使用 ltrace 跟踪动态加载的库调用
我有一个 C 程序，使用动态加载的库来加载插件。 我想跟踪库调用以调试插件的加载。
我查看了 ltrace，但似乎无法使其正常工作：
这是一个示例程序：
#include <stdio.h>
#include <stdlib.h>
#include <dlfcn.h>
int main() {
int *a = malloc(sizeof(int));
void *handle;
double (*cosine)(double);
char *error;
handle = dlopen ("/usr/lib/x86_64-linux-gnu/libm.so.6",RTLD_LAZY);
if (!handle) {
fputs (dlerror(),stderr);
exit(1);
}
cosine = dlsym(handle,"cos");
if ((error = dlerror()) != NULL) {
fputs(error,stderr);
exit(1);
}
printf ("%f\n",(*cosine)(2.0));
dlclose(handle);
return 0;
}
正在编译（并删除 PIE，否则 ltrace 将看不到任何内容）：
gcc main.c -pg -ldl -no-pie
正在运行：ltrace ./a.out
输出
__monstartup(0x401170,0x401431,0x7fffe3875838,0x7fffe3875838) = 0
__cxa_atexit(0x7f712aa98ba0,0) = 0
malloc(4) = 0x76ea30
dlopen("/usr/lib/x86_64-linux-gnu/libm.s"...,1) = 0x76ea80
dlsym(0x76ea80,"cos") = 0x7f712a8abd00
dlerror() = nil
printf("%f\n",-0.416147-0.416147
) = 10
dlclose(0x76ea80) = 0
+++ exited (status 0) +++
如您所见，对 cos 的调用已被跳过。
我如何用这些参数来追踪它？
我尝试了uftrace
但同样，它不会跟踪 cos 调用：
uftrace -a --libname --nest-libcall ./a.out
-0.416147
# DURATION TID FUNCTION
[ 8300] | main() {
1.754 us [ 8300] | malloc@libc-2.31.so(4) = 0x15c6120;
509.774 us [ 8300] | dlopen@libdl-2.31.so("/usr/lib/x86_64-linux-gnu/libm.so.6",RTLD_LAZY) = 0x7ff70ae4d090;
2.140 us [ 8300] | dlsym@libdl-2.31.so(0x7ff70ae4d090,"cos") = 0x7ff70aa61d00;
0.463 us [ 8300] | dlerror@libdl-2.31.so() = "NULL";
332.451 us [ 8300] | printf@libc-2.31.so("%f\n") = 10;
2.134 us [ 8300] | dlclose@libdl-2.31.so(0x7ff70ae4d090) = 0;
958.926 us [ 8300] | } /*
这很令人惊讶，因为在这个 comment 上它看起来很有效。
在 Ubuntu 20.04 上运行
- 跟踪：
0.7.3 - uftrace：
0.9.3
感谢您的帮助！
解决方法
yugr 答案在这种情况下最相关。然而，即使在补丁中使用 ltrace 时，用法也不是直接的。
重要的部分是使用 -x 选项，否则通过 dlopen 加载库的符号将不会显示。 NEWS 中陈述了这一事实：
*** 支持从 dlopen 打开的库中跟踪符号
这些符号由 -x 选择。
幸运的是，我们可以将它设置为显示与我们的库地址匹配的所有符号，这是通过使用 ltrace 手册页中描述的特殊 glob 格式实现的。
我的用例是调试通过 dlopen 加载的自定义 alsa-lib 插件：
# ltrace -x "@libdl.so.2" -x "*@libcustom.so" -f aplay -D custom test.wav
[pid 4183] snd_pcm_hw_params(0x5598dc8ce0,0x7fe4d76fe0,0xa3377eac3f8c3d00,0 <unfinished ...>
[pid 4183] dlopen@libdl.so.2(0x5598dc5db0,1,0x5598dc8a4c,0 <unfinished ...>
[pid 4183] _init@libdirac_dldsp.so(4,0x7fe4d77858,0x7fe4d77880,0x7fa61ce0d8 <unfinished ...>
....
[pid 4183] dlsym@libdl.so.2(0x5598dc8ef0,0x7fa65b1e48,0) = 0x7fa61cf890
[pid 4183] dl_descriptor@libcustom.so(0x7fa61cf890,0x7fa6627988,1) = 0x7fa61fe9e8
.....
[pid 4183] custom_lib_init@libcustom.so(0x7fe4d76770,0x7fa61ffaf0,0 <unfinished ...>
[pid 4183] custom_init@libcustom.so(0x7fe4d76770,3,0) = 0
....
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。