如何跟踪动态加载的库

时间:2014-10-20 16:43:32

标签: linux executable bin objdump

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

现在我怀疑在我们的系统升级过程中,自定义隐藏了原始版本。由于系统的复杂性,修改源代码以便放入一些跟踪是可行的但是很尴尬。我想如果我可以直接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可以告诉我任何区别。但任何建议都表示赞赏!

2 个答案:

答案 0 :(得分:0)

我认为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这样的东西。

或者使用GNU调试器gdb。运行“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) 

答案 1 :(得分:-1)

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

这应该可以解决问题。

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

相关问题