如何跟踪动态加载的库答案

【问题标题】：How to trace which library is dynamically loaded如何跟踪动态加载的库
【发布时间】：2014-10-20 16:43:31
【问题描述】：

我们的系统有一个开源库。棘手的是我们有两个库副本，一个是我们自己修改的，另一个是原始的。两个副本都在源代码树中，但自定义的副本应在运行时调用，而原始副本应在构建时用于其他目的。

现在我怀疑在我们的系统升级过程中，自定义项从原始项中隐藏了。由于系统的复杂性，修改源代码以添加一些痕迹是可行的，但很麻烦。我想我是否可以通过 objdump 顶级库来获得线索。

这里有更多细节：

1) The customization one and the original one have the same source file names 
2) Their library names are same
3) The customization is some implementation change at deep within; so it is 
   invisible from outside
4) The 2 libraries are at different sub directory trees

因为它是动态链接的，我实际上怀疑 objdump 能否告诉我任何区别。但任何建议都值得赞赏！

【问题讨论】：

标签： linux executable bin objdump

【解决方案1】：

我认为 ldd 应该简单地告诉您这一点，作为预测而不是作为跟踪。例如对于 ls 命令：

# ldd $(which ls)
    linux-vdso.so.1 (0x00000333f2a54000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00000333f2610000)
    libcap.so.2 => /lib64/libcap.so.2 (0x00000333f2408000)
    libacl.so.1 => /lib64/libacl.so.1 (0x00000333f21f8000)
    libc.so.6 => /lib64/libc.so.6 (0x00000333f1e48000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000333f1c40000)
    libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00000333f19d8000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000333f17b8000)
    /lib64/ld-linux-x86-64.so.2 (0x00000333f2838000)
    libattr.so.1 => /lib64/libattr.so.1 (0x00000333f15b0000)

为了追踪，你可以在抱怨模式下滥用 apparmor 之类的东西。

或者使用 gdb，GNU 调试器。运行“ls”命令的示例：

# gdb ls
GNU gdb (GDB; openSUSE 13.1) 7.6.50.20130731-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
..
Reading symbols from /usr/bin/ls...Missing separate debuginfo for /usr/bin/ls
Try: zypper install -C "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"
(no debugging symbols found)...done.
(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Temporary breakpoint 1 (main) pending.
Starting program: /usr/bin/ls 
warning: Cannot call inferior functions, Linux kernel PaX protection forbids return to non-executable pages!
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C "debuginfo(build-id)=afa98667969782208459e394f8c8f87ac7510710"
bak  core   learning.log       learning.mode  lr   old          test.log   testpolicy        testpolicy.large
c    learn  learning.log.uniq  ll             lrw  paxtest.log  test2.log  testpolicy.gradm  testpolicy.large.gradm
[Inferior 1 (process 25609) exited normally]
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x00000342a0556ae0  0x00000342a056ee10  Yes (*)     /lib64/ld-linux-x86-64.so.2
(*): Shared library is missing debugging information.
(gdb)

【讨论】：

gdb 解决方案最接近我所寻找的。问题：我进入函数后，我怎么知道我在哪个库？ “show sharedlib”对我不起作用，因为许多库已存档（或其他原因，反正我看不到库）
我对 gdb 了解不多。顺便说一句，您还可以使用 lsof，例如。 lsof -Pn | grep yourappname | grep "\.so"

【解决方案2】：

修改您的类路径（如果这是一个 java 应用程序）并在原始 jar 之前添加此自定义 jar。

这应该可以解决问题。

有时构建时使用的类路径会在运行时保存和使用，但您仍然可以在 java 的命令行参数中修改它以获取类路径条目，或者如果它从 tomcat 内部运行，您仍然可以这样做.

【讨论】：