Как отслеживать динамическую загрузку библиотеки

Question

Наша система имеет библиотеку с открытым исходным кодом. Трудность в том, что у нас есть 2 экземпляра библиотеки, одна из них с нашей собственной модификацией, а другая - оригинал. Обе копии находятся в исходном дереве, но настраиваемый должен быть вызван во время выполнения, а исходный - во время сборки для других целей.

Теперь я подозреваю, что во время нашего обновления системы настройка была скрыта от оригинальной. Из-за сложности системы, можно сделать это, но неловко изменить исходный код, чтобы добавить несколько следов. Я думаю, если бы я мог просто 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 может сказать мне никакой разницы. Но любое предложение приветствуется!

Answer 1

изменить свой путь к классу (если это приложение Java) и добавить эту настраиваемую банку до того, который был оригинальным.

это должно решить проблему.

Ну, иногда путь к классам, используемый во время сборки, сохраняется и используется во время выполнения, но вы все равно можете изменить это в параметрах командной строки java для элемента pathpath, или если его получение выполняется внутри tomcat, вы все равно можете выполнить одна и та же.

Answer 2

Я думаю, что 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)