【问题标题】:How to trace dynamically loaded library calls with ltrace如何使用 ltrace 跟踪动态加载的库调用
【发布时间】:2021-03-30 04:21:36
【问题描述】:

我有一个 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, 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 上运行

  • ltrace:0.7.3
  • uftrace:0.9.3

感谢您的帮助!

【问题讨论】:

    标签: c trace dlopen dynamic-library ltrace


    【解决方案1】:

    您需要添加一个特殊标志 -x pattern 以强制跟踪 dlopen-ed 库中的符号(最简单的是 -x '*',有关更多详细信息,请参阅 @nayana 的答案。)

    旧版本的ltrace 不包含来自https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537781 的相关补丁(点击链接到timetobleed.com),因此它们无法追踪dlopen-ed 库。

    【讨论】:

    • AFAIK ltrace 在版本 0.7.3 中确实有 -x 选项,timetobleed.com 上的引用使用版本 0.5
    【解决方案2】:

    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, 1, 0)                                                                                      = 0x7fa61cf890
    [pid 4183] dl_descriptor@libcustom.so(0x7fa61cf890, 0, 0x7fa6627988, 1)                                                                       = 0x7fa61fe9e8
    .....
    [pid 4183] custom_lib_init@libcustom.so(0x7fe4d76770, 0x7fa61ffaf0, 0, 0 <unfinished ...>
    [pid 4183] custom_init@libcustom.so(0x7fe4d76770, 1, 3, 0)                                                                                      = 0
    ....
    

    【讨论】:

    • 不错。请注意,也可以简单地使用-x '*'
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2015-11-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-04-14
    • 1970-01-01
    相关资源
    最近更新 更多